Re: [PATCH v9 30/32] timers: Implement the hierarchical pull model

[Anna-Maria Behnsen]

Anna-Maria Behnsen <anna-maria@xxxxxxxxxxxxx> writes:

> Sebastian Siewior <bigeasy@xxxxxxxxxxxxx> writes:
>
>> On 2023-12-01 10:26:52 [+0100], Anna-Maria Behnsen wrote:
>>
>> This whole thing confuses me.
>> If the CPU goes offline, it needs to get removed from the migration
>> hierarchy and this is it. Everything else is handled by the migrator. If
>> the migrator is going offline then it needs wake a random CPU and make
>> sure it takes the migrator role. I am confused by the whole ::wakeup and
>> ::wakeup_recalc thingy.
>>
>
> wakeup_recalc is required to indicate, that the CPU was chosen as the
> new migrator CPU when the last active CPU in timer migration hierarchy
> went offline.
>
> When a CPU goes idle and it is the last active CPU in the timer
> migration hierarchy, it has to make sure that it wakes up in time to
> handle the first event of the hierarchy. On the normal idle path this is
> not a problem as the value of the first event of the hierarchy is
> returned. But when an IRQ occurs on this idle CPU, the timers are
> revisited again. But then it is also required that the first event of
> the timer migration hierarchy is still considered, as the CPU cannot
> make sure another CPU will handle it. So the value is stored on idle
> path to tmc->wakeup. Otherwise every idle CPU has to walk the hierarchy
> again after an IRQ to make sure nothing is lost as the CPU doesn't know
> what happend in the meantime. I'm aware, that it is possible that
> several CPUs have the same wakeup value when there is no new first event
> and if the hierarchy is idle and some CPUs become active and go idle
> directly again. But if we want to cover this, we need a single point
> with the first event and with the last migrator information and I'm
> quite sure that it will not scale.
>

I forgot to explain one thing: A CPU does remote expiry and it is
possible that the CPU is idle in timer migration hierarchy. Therefore
the wakeup value is updated at the end of remote handling with the new
first event of the timer migration hierarchy unconditionally.

Thanks,
	Anna-Maria