Messages in this thread | | | Date | Mon, 26 Apr 2021 12:35:33 +0100 | From | Mel Gorman <> | Subject | Re: [PATCH 00/10] sched/fair: wake_affine improvements |
| |
On Mon, Apr 26, 2021 at 04:00:32PM +0530, Srikar Dronamraju wrote: > * Mel Gorman <mgorman@techsingularity.net> [2021-04-23 13:38:55]: > > Hi Mel, > > > On Fri, Apr 23, 2021 at 04:01:29PM +0530, Srikar Dronamraju wrote: > > > > The series also oopses a *lot* and didn't get through a run of basic > > > > workloads on x86 on any of three machines. An example oops is > > > > > > > > > > Can you pass me your failing config. I am somehow not been seeing this > > > either on x86 or on Powerpc on multiple systems. > > > > The machines have since moved onto testing something else (Rik's patch > > for newidle) but the attached config should be close enough. > > > > > Also if possible cat /proc/schedstat and cat > > > /proc/sys/kernel/sched_domain/cpu0/domain*/name > > > > > > > For the vanilla kernel > > > > SMT > > MC > > NUMA > > I was able to reproduce the problem and analyze why it would panic in > cpus_share_cache. > > In my patch(es), we have code snippets like this. > > if (tsds->idle_core != -1) { > if (cpumask_test_cpu(tsds->idle_core, p->cpus_ptr)) > return tsds->idle_core; > return this_cpu; > } > > Here when we tested the idle_core and cpumask_test_cpu, > tsds->idle_core may not have been -1; However by the time it returns, > tsds->idle_core could be -1; > > cpus_share_cpus() then tries to find sd_llc_id for -1 and crashes. > > Its more easier to reproduce this on a machine with more cores in a > LLC than say a Power10/Power9. Hence we are hitting this more often > on x86. > > One way could be to save the idle_core to a local variable, but that > negates the whole purpose since we may end up choosing a busy CPU. I > will find a way to fix this problem. >
As there is no locking that protects the variable, it's inherently race-prone. A READ_ONCE to a local variable may be your only choice
-- Mel Gorman SUSE Labs
| |