2013/3/11 Ingo Molnar <mi...@kernel.org>: > > * Frederic Weisbecker <fweis...@gmail.com> wrote: > >> > - Please outline how the current TODO entries affect upstream >> > mergability. Does it reduce the 'full'-ness of this dynticks mode? >> > Outright buggy behavior? Other trade-offs? >> >> Mostly this is about upstream features that won't be working with the current >> state of the art: enqueuing a posix cpu timer on a nohz CPU may result in it >> being >> ignored by the target due to the lack of ticking until expiration, perf >> events may >> not be round-robined, etc... I'll make sure to document all these items. > > So it's "buggy behavior of existing features" it appears?
Right. > It would be really useful to add some sort of 'make it safe easily' mechanism: > > - if a posix timer is enqueued on a CPU, then the CPU should have a timer > ticking > > - if perf events are active on a CPU, then it should have a timer ticking > > this would make it mergable, as most of the time systems don't have any of > these > facilities active. Plus this dynticks-off mechanism would also allow us to > cover any > other (still unknown) facility that regresses. So it would be nice to have > that > option. Yeah that's how I intended to solve the issue for these cases. I don't worry that much about posix cpu timers and perf in fact. These should be not hard to cope with. I'm more worried about scheduler details in scheduler_tick(). I covered the rq clock and a part of update_cpu_load_active(). Now we have yet to care about sched_avg_update(), calc_load_account_active() and sched_class::task_tick() to make sure we are not letting something behind. There is rq->rt_avg that seem to be used for load balancing when rt tasks are around. Then calc_load_update. Idle load balancing is concerned as well. I haven't looked deeply into these places so I don't know what can be shortcut or not there. > Later on we could gradually eliminate these limitations. It would also be > apparent > where they are, just from grepping the source. > > If that's done, and if it tests fine for a few weeks then this could be v3.10 > material IMO. Ok, I won't be that optimistic about the release time but things are certainly going to be faster now. I'm going to reshape and send you what I have now then we'll have a fresher view of the rest. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
