On Wed, Oct 03, 2007 at 10:16:13AM +0200, Ingo Molnar wrote: > > * Jarek Poplawski <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/