Messages in this thread | | | Date | Wed, 3 Oct 2007 10:56:36 +0200 | From | Jarek Poplawski <> | Subject | Re: Network slowdown due to CFS |
| |
On Wed, Oct 03, 2007 at 10:16:13AM +0200, Ingo Molnar wrote: > > * Jarek Poplawski <jarkao2@o2.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |