Messages in this thread | | | Date | Mon, 11 Mar 2013 17:38:42 +0100 | Subject | Re: [ANNOUNCE] 3.9-rc1-nohz1 | From | Frederic Weisbecker <> |
| |
2013/3/11 Ingo Molnar <mingo@kernel.org>: > > * Frederic Weisbecker <fweisbec@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.
| |