Messages in this thread | | | Date | Mon, 13 Sep 2010 16:19:13 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running |
| |
* Ingo Molnar (mingo@elte.hu) wrote: > > * Mike Galbraith <efault@gmx.de> wrote: > > > On Sun, 2010-09-12 at 14:16 -0400, Mathieu Desnoyers wrote: > > > > Or am I missing your point ? > > > > Yes and no. I'm pondering the parent, but by the same token, the > > vfork child shouldn't be penalized either. > > > > Does your latency go down drastically if you turn START_DEBIT off? > > Seems like it should. Perhaps START_DEBIT should not start a task > > further right than rightmost. I've done that before. > > > > maximum latency: 19221.5 µs > > average latency: 5159.0 µs > > missed timer events: 0 > > > > maximum latency: 43901.0 µs > > average latency: 8430.1 µs > > missed timer events: 0 > > > > Turning it off here cut latency roughly in half (i've piddled vfork > > though, but not completely). Limiting child placement to no further > > right than rightmost should help quite a bit. > > Very interesting observation. Mathieu, mind testing Mike's suggestion > with wakeup-latency.c?
Sure. this is with the smaller min_granularity:
With START_DEBIT:
maximum latency: 21111.1 µs average latency: 4188.2 µs missed timer events: 0
Without:
maximum latency: 6670.2 µs average latency: 1586.0 µs missed timer events: 0
So yes, as expected, it makes a huge difference. This is because SIGEV_THREAD creates a new thread each time the timer fires, and newly created tasks are put at the end of the runqueue with START_DEBIT.
However, removing START_DEBIT makes my Xorg feel less responsive (again, just my own impression). We might need a more suitable way to deal with forks than just putting the newly forked task at the end of the spread, but just putting it at the beginning of the spread does not seem to do well neither.
One idea: we could temporarily tweak the nice value of both the parent and the child after a fork to a lower nice value, but only apply this for their first slice after the fork. The goal behind this is that their respective vruntime will increment faster in the first slice after the fork, so a fork bomb (worse-case) will end up running with a very very low nice level. With this measure in place, START_DEBIT might not be needed. Thoughts ?
Thanks,
Mathieu
> > Thanks, > > Ingo
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- 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/
| |