Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH 6/7 v3] sched/fair: trigger the update of blocked load on newly idle cpu | Date | Wed, 17 Feb 2021 11:51:02 +0000 |
| |
On 15/02/21 16:02, Vincent Guittot wrote: > On Fri, 12 Feb 2021 at 20:19, Valentin Schneider > <valentin.schneider@arm.com> wrote: >> I don't think there is anything inherently wrong with it - the >> nohz_idle_balance() call resulting from the kick_ilb() IPI will just bail >> out due to the flags being cleared here. This wasn't immediately clear to >> me however. > > In fact, I forgot to replace the WARN_ON in nohz_csd_func() by a > simple return as reported by kernel test robot / oliver.sang@intel.com >
Can't that actually be a problem? kick_ilb() says:
* Access to rq::nohz_csd is serialized by NOHZ_KICK_MASK; he who sets * the first flag owns it; cleared by nohz_csd_func().
So if you have:
kick_ilb() -> kicks CPU42
And then said CPU42 goes through, before nohz_csd_func(),:
do_idle() -> nohz_run_idle_balance()
you could have yet another CPU do:
kick_ilb() -> kicks CPU42
which would break rq->nohz_csd serialization.
>> >> > +} >> > +
| |