lkml.org 
[lkml]   [2007]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Network slowdown due to CFS
    On Wed, Oct 03, 2007 at 11:10:58AM +0200, Ingo Molnar wrote:
    >
    > * Jarek Poplawski <jarkao2@o2.pl> wrote:
    >
    > > 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. [...]
    >
    > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-03 11:51    [W:4.848 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site