Messages in this thread | | | Subject | Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running | From | Peter Zijlstra <> | Date | Mon, 13 Sep 2010 16:16:38 +0200 |
| |
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.
| |