Srikar Dronamraju <sri...@linux.vnet.ibm.com> writes:
> * Michael Ellerman <patch-notificati...@ellerman.id.au> [2018-08-21 20:35:23]:
>
>> On Fri, 2018-08-17 at 14:54:39 UTC, Srikar Dronamraju wrote:
>> > On a shared lpar, Phyp will not update the cpu associativity at boot
>> > time. Just after the boot system does recognize itself as a shared lpar and
>> > trigger a request for correct cpu associativity. But by then the scheduler
>> > would have already created/destroyed its sched domains.
>> >
>> > This causes
>> > - Broken load balance across Nodes causing islands of cores.
>> > - Performance degradation esp if the system is lightly loaded
>> > - dmesg to wrongly report all cpus to be in Node 0.
>> > - Messages in dmesg saying borken topology.
>> > - With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity
>> > node sched domain"), can cause rcu stalls at boot up.
>> >
>> >
>> > Previous attempt to solve this problem
>> > https://patchwork.ozlabs.org/patch/530090/
>> >
>> > Reported-by: Manjunatha H R <manju...@in.ibm.com>
>> > Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
>>
>> Applied to powerpc next, thanks.
>>
>> https://git.kernel.org/powerpc/c/2ea62630681027c455117aa471ea3a
>>
>
> Once it gets to Linus's tree, can we request this to be included in
> stable trees?
You can yes.
I'd prefer if we wait a week or two so it can get some testing first.
cheers
