Messages in this thread | | | Subject | Re: [RFC PATCH 00/11] sched: CFS low-latency features | From | Peter Zijlstra <> | Date | Thu, 26 Aug 2010 20:57:25 +0200 |
| |
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.
| |