Messages in this thread | | | Date | Fri, 14 Sep 2007 10:17:35 +0200 | From | Ingo Molnar <> | Subject | Re: [announce] CFS-devel, performance improvements |
| |
* dimm <dmitry.adamushko@gmail.com> wrote:
> and here's something a bit more intrusive. > > The initial idea was to completely get rid of 'se->fair_key'. It's > always equal to 'se->vruntime' for all runnable tasks but the > 'current'. The exact key within the tree for the 'current' has to be > known in order for __enqueue_entity() to work properly (if we just use > 'vruntime', we may go a wrong way down the tree while looking for the > correct position for a new element). Sure, it's possible to cache the > current's key in the 'cfs_rq' and add a few additional checks, but > that's not very nice... so what if we don't keep the 'current' within > the tree? :-) > > The illustration is below. Some bits can be missed so far but a > patched kernel boots/works (haven't done real regression tests yet... > can say that the mail client is still working at this very moment :-). > > There are 2 benefits: > > (1) no more 'fair_key' ; > (2) entity_tick() is simpler/more effective : 'update_curr()' now vs. > 'dequeue_entity() + enqueue_entity()' before.
cool patch - i like it! It removes some code as well, besides shrinking struct task_struct with another 64-bit variable - so it's a nice speedup:
text data bss dec hex filename 34467 3466 24 37957 9445 sched.o.before 34414 3466 24 37904 9410 sched.o.after
i've applied it to the end of the queue - it depends on whether ->vruntime works out well.
Ingo - 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/
| |