Re: [RFC PATCH 00/11] sched: CFS low-latency features

[Peter Zijlstra <peterz@infradead.org>]

On Thu, 2010-08-26 at 14:09 -0400, Mathieu Desnoyers wrote:
> Feedback is welcome,
> 
So we have the following components to this patch:

  - dynamic min_vruntime -- push the min_vruntime ahead at the
       rate of the runqueue wide virtual clock. This approximates
       the virtual clock, esp. when turning off sleeper fairness.
       And is cheaper than actually computing the virtual clock.

       It allows for better insertion and re-weighting behaviour,
       but it does increase overhead somewhat.

  - special wakeups using the next-buddy to get scheduled 'soon',
       used by all wakeups from the input system and timers.

  - special fork semantics related to those special wakeups.


So while I would love to simply compute the virtual clock, it would add
a s64 mult to every enqueue/dequeue and a s64 div to each
enqueue/re-weight, which might be somewhat prohibitive, the dyn
min_vruntime approximation seems to work well enough and costs a u32 div
per enqueue.

Adding a preference to all user generated wakeups (input) and
propagating that state along the wakeup chain seems to make sense,
adding the same to all timers is something that needs to be discussed, I
can well imagine not all timers are equally important -- do we want to
extend the timer interface?

If we do decide we want both, we should at the very least merge the
try_to_wake_up() conditional blob (they're really identical). Preferably
we should reduce ttwu(), not add more to it... 

Fudging fork seems dubious at best, it seems generated by the use of
timer_create(.evp->sigev_notify = SIGEV_THREAD), which is a really
broken thing to do, it has very ill defined semantics and is utterly
unable to properly cope with error cases. Furthermore its trivial to
actually correctly implement the desired behaviour, so I'm really
skeptical on this front; friends don't let friends use SIGEV_THREAD.