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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 3 Oct 2007 10:56:36 +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 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. (Btw, in -rc8-mm2 I see new sched_slice() function which
seems to return... time.)

> 
> In the 2.6.22 scheduler, there was a p->time_slice per task variable 
> that could be manipulated. (Note, in 2.6.22's sched_yield() did not 
> manipulate p->time_slice.)
> 
> sysctl_sched_latency on the other hand is not something that is per task 
> (it is global) so there is no pending timeslice to be "cleared" as it 
> has been suggested naively.

But, there is this "something", very similar and very misleading, you
count eg. in check_preempt_curr_fair to find if time is over, and I
think this could be similar enough to what David Schwartz wanted to
use in his idea, and you didn't care to explain why it's so different?

Jarek P.
-
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/