[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bn4wtfyec4mfoztcr35rctgcbibypjh5gmxdr3fro72glh2y3n@vmqsuxgjlonw>
Date: Thu, 21 Mar 2024 08:51:40 +0100
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Tony Luck <tony.luck@...el.com>
CC: Fenghua Yu <fenghua.yu@...el.com>, Reinette Chatre
<reinette.chatre@...el.com>, Peter Newman <peternewman@...gle.com>, "Jonathan
Corbet" <corbet@....net>, Shuah Khan <skhan@...uxfoundation.org>,
<x86@...nel.org>, Shaopeng Tan <tan.shaopeng@...itsu.com>, James Morse
<james.morse@....com>, Jamie Iles <quic_jiles@...cinc.com>, Babu Moger
<babu.moger@....com>, Randy Dunlap <rdunlap@...radead.org>, Drew Fustini
<dfustini@...libre.com>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v16 0/9] Add support for Sub-NUMA cluster (SNC) systems
Hi Tony,
On 2024-03-12 at 14:42:38 -0700, Tony Luck wrote:
>The Sub-NUMA cluster feature on some Intel processors partitions the CPUs
>that share an L3 cache into two or more sets. This plays havoc with the
>Resource Director Technology (RDT) monitoring features. Prior to this
>patch Intel has advised that SNC and RDT are incompatible.
>
>Some of these CPU support an MSR that can partition the RMID counters in
>the same way. This allows monitoring features to be used. With the caveat
>that users must be aware that Linux may migrate tasks more frequently
>between SNC nodes than between "regular" NUMA nodes, so reading counters
>from all SNC nodes may be needed to get a complete picture of activity
>for tasks.
>
>Cache and memory bandwidth allocation features continue to operate at
>the scope of the L3 cache.
>
>Signed-off-by: Tony Luck <tony.luck@...el.com>
>
>---
>Changes since v15: Link: https://lore.kernel.org/all/20240228112935.8087-tony.luck@intel.com/
>
>0) Note that v14 Reviewed/Testing tags have been removed because of the
> extent of refactoring to catch up with upstream. But nothing
> fundamental changed, so everything should look familiar.
>
>1) Refactor to apply on top of Link: https://lore.kernel.org/all/20240308213846.77075-1-tony.luck@intel.com/
> [So base commit is either tip x86/cache, or upstream current merge PLUS
> the two patches in that series]
I'm having problems with cleanly applying this series. Here are the steps I
took:
- I pulled this series with b4.
- I pulled two patches from the "Pass domain to target CPU" series with b4.
- Then I hard reseted my branch to tip x86/cache
- Tried applying first the two patches and then this series.
And here I'm getting conflicts on patch 0002 "Prepare to split rdt_domain
structure". I also tried with tip master and applying James Morse's series
before your patches but I got the same problem. Am I doing something wrong?
I wanted to find what causes the conflict so I can give more details but three
way merging doesn't seem to work and git am doesn't leave any conflict markers,
just fails.
--
Kind regards
Maciej Wieczór-Retman
Powered by blists - more mailing lists