lkml.org 
[lkml]   [2010]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running
    From
    Date
    On Mon, 2010-09-13 at 09:56 -0400, Mathieu Desnoyers wrote:
    >
    > > One option is to simply get rid of that stuff in check_preempt_tick()
    > > and instead do a wakeup-preempt check on the leftmost task instead.
    > >
    > > The code as it stands today does that delta_exec < min_gran check to
    > > ensure current gets some runtime before doing that second preemption
    > > check, which compares vruntime with a wall-time measure.
    > >
    > > Making that gran more complex doesn't really buy us much because for a
    > > system with different weights in the gran and slice lengths don't match
    > > up anyway.
    >
    > So I bet this last sentence is about the example of a system with many nice 19
    > processes I told you about on IRC. Yes, this one is a bummer, as we would not
    > like to count them as running threads at all.

    Of course we would. But the same is true for -5 and 5 threads together.

    > > static void
    > > check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
    > > {
    > > - unsigned long ideal_runtime, delta_exec;
    > > + unsigned long slice = sched_slice(cfs_rq, curr);
    >
    > So you still compute the sched_slice(), based on sched_period(), based on
    > sysctl_sched_min_granularity *= nr_running when there are more than nr_latency
    > running threads.

    What's wrong with that? I keep asking you, you keep not giving an
    answer. Stop focussing on nr_latency, its an by produce not a
    fundamental entity.

    period := max(latency, min_gran * nr_running)

    See, no nr_latency -- the one and only purpose of nr_latency is avoiding
    that multiplication when possible.


    > > - if (delta_exec < sysctl_sched_min_granularity)
    > > - return;
    >
    > Well, the reason why this test is here seems to be that we don't want to trigger
    > "resched_task" more often than needed, and here it's defined by the granularity.

    Right, but its wrong for the weighted case. Letting a light task run
    that long will make its latency suck.

    > I don't quite see with what you are replacing this, other than "let's set the
    > resched flag all the time to save a 32-bit division". I figure out it's more
    > expensive the call the scheduler than to do a 32-bit div.

    The more divs we put it, the more expensive it all becomes.




    \
     
     \ /
      Last update: 2010-09-13 16:19    [W:4.062 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site