Re: [patch 1/4] - Potential performance bottleneck for Linxu TCP

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Thu, Nov 30, 2006 at 08:35:04AM +0100, Ingo Molnar (mingo@elte.hu) wrote:
> what was observed here were the effects of completely throttling TCP 
> processing for a given socket. I think such throttling can in fact be 
> desirable: there is a /reason/ why the process context was preempted: in 
> that load scenario there was 10 times more processing requested from the 
> CPU than it can possibly service. It's a serious overload situation and 
> it's the scheduler's task to prioritize between workloads!
> 
> normally such kind of "throttling" of the TCP stack for this particular 
> socket does not happen. Note that there's no performance lost: we dont 
> do TCP processing because there are /9 other tasks for this CPU to run/, 
> and the scheduler has a tough choice.
> 
> Now i agree that there are more intelligent ways to throttle and less 
> intelligent ways to throttle, but the notion to allow a given workload 
> 'steal' CPU time from other workloads by allowing it to push its 
> processing into a softirq is i think unfair. (and this issue is 
> partially addressed by my softirq threading patches in -rt :-)

Doesn't the provided solution is just a in-kernel variant of the
SCHED_FIFO set from userspace? Why kernel should be able to mark some
users as having higher priority?
What if workload of the system is targeted to not the maximum TCP
performance, but maximum other-task performance, which will be broken
with provided patch.

> 	Ingo

-- 
	Evgeniy Polyakov