linux-kernel - Re: Network slowdown due to CFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071003091058.GB7802@elte.hu>
Date:	Wed, 3 Oct 2007 11:10:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jarek Poplawski <jarkao2@...pl>
Cc:	David Schwartz <davids@...master.com>, linux-kernel@...r.kernel.org
Subject: Re: Network slowdown due to CFS

* Jarek Poplawski <jarkao2@...pl> wrote:

> On Wed, Oct 03, 2007 at 10:16:13AM +0200, Ingo Molnar wrote:
> > 
> > * Jarek Poplawski <jarkao2@...pl> wrote:
> > 
> > > > firstly, there's no notion of "timeslices" in CFS. (in CFS tasks 
> > > > "earn" a right to the CPU, and that "right" is not sliced in the 
> > > > traditional sense) But we tried a conceptually similar thing [...]
> > > 
> > > >From kernel/sched_fair.c:
> > > 
> > > "/*
> > >  * Targeted preemption latency for CPU-bound tasks:
> > >  * (default: 20ms, units: nanoseconds)
> > >  *
> > >  * NOTE: this latency value is not the same as the concept of
> > >  * 'timeslice length' - timeslices in CFS are of variable length.
> > >  * (to see the precise effective timeslice length of your workload,
> > >  *  run vmstat and monitor the context-switches field)
> > > ..."
> > > 
> > > So, no notion of something, which are(!) of variable length, and which 
> > > precise effective timeslice lenght can be seen in nanoseconds? (But 
> > > not timeslice!)
> > 
> > You should really read and understand the code you are arguing about :-/
> 
> Maybe you could help me with better comments? IMHO, it would be enough 
> to warn new timeslices have different meaning, or stop to use this 
> term at all. [...]

i'm curious, what better do you need than the very detailed comment 
quoted above? Which bit of "this latency value is not the same as the 
concept of timeslice length" is difficult to understand? The timeslices 
of tasks (i.e. the time they spend on a CPU without scheduling away) is 
_not_ maintained directly in CFS as a per-task variable that can be 
"cleared", it's not the metric that drives scheduling. Yes, of course 
CFS too "slices up CPU time", but those slices are not the per-task 
variables of traditional schedulers and cannot be 'cleared'.

> [...] (Btw, in -rc8-mm2 I see new sched_slice() function which seems 
> to return... time.)

wrong again. That is a function, not a variable to be cleared. (Anyway, 
the noise/signal ratio is getting increasingly high in this thread with 
no progress in sight, so i cannot guarantee any further replies - 
possibly others will pick up the tab and explain/discuss any other 
questions that might come up. Patches are welcome of course.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/