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]

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

On Wed, Oct 03, 2007 at 11:10:58AM +0200, Ingo Molnar wrote:
> 
> * 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'.

It's not about this comment alone, but this comment plus "no notion"
comment, which appears in sched-design-CFS.txt too.

> 
> > [...] (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.)

I can't see anything about clearing. I think, this was about charging,
which should change the key enough, to move a task to, maybe, a better
place in a que (tree) than with current ways.

Jarek P.

PS: Don't you think that a nice argue with some celebrity, like Ingo
Molnar himself, is by far more interesting than those dull patches?
-
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/