lkml.org 
[lkml]   [2013]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [ANNOUNCE] 3.9-rc1-nohz1
From
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.


\
 
 \ /
  Last update: 2013-03-11 18:21    [W:0.051 / U:23.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site