Re: [PATCH 5.4 0/2] Backports "x86, sched: Treat Intel SNC topology as default, COD as exception"

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Jun 16, 2021 at 10:59:46PM +0000, Sherry Yang wrote:
> 
> > On Jun 7, 2021, at 5:37 PM, Sherry Yang <sherry.yang@oracle.com> wrote:
> > 
> > Could you also backport these two commits
> > adefe55e7258 ("x86/kernel: Convert to new CPU match macros")
> > 2c88d45edbb8 ("x86, sched: Treat Intel SNC topology as default,
> > COD as exception") to 5.4.y?
> > 
> > Commit adefe55e7258 ("x86/kernel: Convert to new CPU match macros")
> > is a prerequisite of the second commit. There are conflicts while
> > cherry-picking commit adefe55e7258 ("x86/kernel: Convert to new
> > CPU match macros"), which are caused by a later commit
> > c84cb3735fd5 ("x86/apic: Move TSC deadline timer debug printk").
> > Keep the later code base.
> > 
> > Alison Schofield (1):
> >  x86, sched: Treat Intel SNC topology as default, COD as exception
> > 
> > Thomas Gleixner (1):
> >  x86/kernel: Convert to new CPU match macros
> > 
> > arch/x86/kernel/apic/apic.c | 32 ++++++-------
> > arch/x86/kernel/smpboot.c   | 90 +++++++++++++++++++------------------
> > arch/x86/kernel/tsc_msr.c   | 14 +++---
> > arch/x86/power/cpu.c        | 16 +------
> > 4 files changed, 68 insertions(+), 84 deletions(-)
> > 
> > -- 
> > 2.27.0
> > 
> 
> Hi,
>  
> We have seen that the warning “sched: CPU #20's llc-sibling CPU #0 is not on 
> the same node! [node: 1 != 0]. Ignoring dependency. ” applies to 5.4 but we don’t 
> observe the fix in 5.4. I'm sending this email to apply the fix from upstream 
> 2c88d45edbb8 ("x86, sched: Treat Intel SNC topology as default, COD as 
> exception") to 5.4 and also resolve the dependency conflict caused by 
> prerequisite commit adefe55e7258 ("x86/kernel: Convert to new CPU match 
> macros”) by keeping the later code base, please refer to the
> previous two patches for the detail.
>  

I have no idea what you want me to do here, sorry.

Please provide a working, tested, set of patches backported to the
relevant stable trees you want to see them applied to, and I will be
glad to review and queue them up if they look good.  No one here is in
the position to "resolve the dependency conflict" of anything here for
you, sorry, you will need to do this yourself as you are in the best
position to do so.

thanks!

greg k-h