* Jarek Poplawski <[email protected]> wrote:
> 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. [...]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
