lkml.org 
[lkml]   [2007]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RSDL v0.31
    Date
    Con Kolivas wrote:
    > DEF_TIMESLICE is a value used for smp balancing and has no effect on quota
    > so I doubt you mean that value. The quota you're describing of not
    > resetting is something like the sleep average idea of current systems
    > where you accumulate bonus points by sleeping when you would be running
    > and redeem them later. This is exactly the system I'm avoiding using in
    > rsdl as you'd have to decide just how much sleep time it could accumulate,
    > and over how long it would run out, and so on. ie that's the interactivity
    > estimator. This is the system that destroys any guarantee of cpu
    > percentage, and ends up leading to periods of relative starvation, is open
    > to tuning that can either be too short or too long depending on the values
    > you chose and so on.

    Ok, but I can clearly see an expiration happening for sleeping tasks, like X.
    It looks like it's climbing a ladder halfway, then it sleeps, and when it
    wakes up, it continues to complete the ladder to expiration. Couldn't this
    sleep be taken into account, and reset the ladder position accordingly?

    > > The thing is, latencies are currently dependent on the number of tasks
    > > in the run-queue; i.e. more rq-tasks means higher latencies, yet fixed
    > > timeslices according to nice. Just switching this the other way around,
    > > by fixing latencies according to nice, and adjusting the timeslices
    > > depending on rq-load, may yield a much more scalable system.
    >
    > That is not really feasible to implement. How can you guarantee latencies
    > when the system is overloaded? If you have 1000 tasks all trying to get
    > scheduled in say 10ms you end up running for only 10 microseconds at a
    > time. That will achieve the exact opposite whereby as the load increases
    > the runtime gets shorter and shorter till cpu cache trashing and no real
    > work occurs.

    Most of the time we only run a small number of tasks. And for the case of
    1000's of tasks, you could put in some lower threshold, that would trigger
    an increase of latency, if the timeslice became ridiculously small.


    Thanks!

    --
    Al

    -
    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-03-17 17:13    [W:3.660 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site