Re: [RFC patch 1/2] sched: dynamically adapt granularity withnr_running

[Mathieu Desnoyers]

* Ingo Molnar (mingo@xxxxxxx) wrote:
> 
> * Mike Galbraith <efault@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/