On Thu 2022-02-17 17:32 +0100, Frederic Weisbecker wrote: > > If I understand correctly, in the context of nohz_full, since such work is > > deferred, it will only be handled in a scenario when the periodic/or > > scheduling-clock tick is enabled i.e. the timer was reprogrammed on exit > > from idle. > > Oh I see, it's a deferrable delayed work... > Then I can see two other issues: > > 1) Can an interrupt in idle modify the vmstat and thus trigger the need to > flush it? I believe it's the case and then the problem goes beyond nohz_full > because if the idle interrupt fired while the tick is stopped and didn't set > TIF_RESCHED, we go back to sleep without calling quiet_vmstat(). Yes: e.g. a nohz_full CPU, in idle code, could indeed receive a reschedule IPI; re-enable local IRQs and generic idle code sees the TIF_NEED_RESCHED flag against the idle task. Additionally, the selected task could indirectly released a few pages [to satisfy a low-memory condition] and modify CPU-specific vmstat data i.e. vm_stat_diff[NR_FREE_PAGES]. > 2) What if we are running task A in kernel mode while the tick is stopped > (nohz_full). Task A modifies the vmstat and goes to userspace for a long > while. > Your patch fixes case 1) but not case 2). The problem is that TIMER_DEFERRABLE > should really be about dynticks-idle only and not dynticks-full. I've always > been afraid about enforcing that rule though because that would break old > noise-free setups. But perhaps I should... If I understand correctly, I agree. For the latter case, nothing can be done unfortunately since the scheduling-clock tick is stopped. Kind regards, -- Aaron Tomlin
