Messages in this thread | | | Subject | Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running | From | Mike Galbraith <> | Date | Tue, 14 Sep 2010 04:27:39 +0200 |
| |
On Mon, 2010-09-13 at 17:53 +0200, Peter Zijlstra wrote: > On Mon, 2010-09-13 at 15:56 +0200, Mike Galbraith 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. > > > > That's what I wanted to boil it down to instead of putting the extra > > preempt check in, but it kills the longish slices of low load. IIRC, > > when I tried that, it demolished throughput. > > Hrm.. yes it would.. > > So the reason for all this: > > /* > * Ensure that a task that missed wakeup preemption by a > * narrow margin doesn't have to wait for a full slice. > * This also mitigates buddy induced latencies under load. > */ > > Is to avoid tasks getting too far ahead in virtual time due to buddies, > right?
Yeah, that was the thought anyway.
> Would something like the below work? Don't actually use delta_exec to > filter, but use wakeup_gran + min_gran on virtual time, (much like Steve > suggested) and then verify using __sched_gran(). > > Or have I now totally confused myself backwards? > > - delta_exec is walltime, and should thus we compared against a > weighted unit like slice, > - delta is a vruntime unit, and is thus weight free, hence we can use > granularity/unweighted units.
I don't think it really matters. Distance is weighted when using slice as the measure.
-Mike
| |