include/linux/cacheinfo.h | 21 ++++++++++++++++----- arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 17 ++++++----------- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 14 +++++--------- 3 files changed, 27 insertions(+), 25 deletions(-)
[get_maintainer.pl is vague about who owns <linux/cacheinfo.h>
to I've scattershooted some of the folks that committed changes
for this file]
This helper function came up in discussion of the resctrl patches
for Sub-NUMA Cluster (SNC) support. Reinette pointed out[1] that there
are already two places where it would clean things up by avoiding
open coding. The SNC patches will add two additional call sites.
So rather than have this jammed up as part of the SNC series, I'm
posting it as a simple standalone cleanup.
Signed-off-by: Tony Luck <tony.luck@intel.com>
[1] https://lore.kernel.org/all/050c64b3-20b3-4db6-b782-f5124ebaab31@intel.com/
Tony Luck (3):
cacheinfo: Add function to get cacheinfo for a given (cpu, cachelevel)
x86/resctrl: Replace open code cacheinfo search in
pseudo_lock_region_init()
x86/resctrl: Replace open code cacheinfo search in
rdtgroup_cbm_to_size()
include/linux/cacheinfo.h | 21 ++++++++++++++++-----
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 17 ++++++-----------
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 14 +++++---------
3 files changed, 27 insertions(+), 25 deletions(-)
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
--
2.45.0
Dear Maintainers,
On 5/31/24 12:57 PM, Tony Luck wrote:
> [get_maintainer.pl is vague about who owns <linux/cacheinfo.h>
> to I've scattershooted some of the folks that committed changes
> for this file]
Thank you to Andrew for picking up this series into the
mm-nonmm-unstable branch. I am not familiar with how patches flow
from this repo/branch but I expect that this inclusion will require some
high level coordination between the big repos since resctrl changes
usually flow upstream through x86/cache branch of tip and I
anticipate some conflicts and also needing to figure out how to deal
with this new dependency in planned resctrl changes.
As Tony mentioned upcoming resctrl changes depend on this new
include/linux/cacheinfo.h addition while some other planned
resctrl changes [2] will conflict with patch #2 and #3 of this series.
A previous change to include/linux/cacheinfo.h (commit
709c4362725a ("cacheinfo: Move resctrl's get_cache_id() to the
cacheinfo header file")) was able to accompany the resctrl
changes via x86/cache of tip. Could it be possible to repeat
such a patch flow?
Looking at mm-nonmm-unstable there is indeed one other pending
change that touches include/linux/cacheinfo.h ("cpumask: make
core headers including cpumask_types.h where possible"). I
confirmed that there is no conflict between it and patch #1
from this series, the two can be applied in any order. Of course,
this means nothing for any other changes to this file
that may arrive later during this cycle.
Could you please provide your guidance on how to achieve a smooth
upstream of this work?
Thank you
Reinette
[2] https://lore.kernel.org/lkml/20240321165106.31602-1-james.morse@arm.com/
> This helper function came up in discussion of the resctrl patches
> for Sub-NUMA Cluster (SNC) support. Reinette pointed out[1] that there
> are already two places where it would clean things up by avoiding
> open coding. The SNC patches will add two additional call sites.
>
> So rather than have this jammed up as part of the SNC series, I'm
> posting it as a simple standalone cleanup.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
>
> [1] https://lore.kernel.org/all/050c64b3-20b3-4db6-b782-f5124ebaab31@intel.com/
>
> Tony Luck (3):
> cacheinfo: Add function to get cacheinfo for a given (cpu, cachelevel)
> x86/resctrl: Replace open code cacheinfo search in
> pseudo_lock_region_init()
> x86/resctrl: Replace open code cacheinfo search in
> rdtgroup_cbm_to_size()
>
> include/linux/cacheinfo.h | 21 ++++++++++++++++-----
> arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 17 ++++++-----------
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 14 +++++---------
> 3 files changed, 27 insertions(+), 25 deletions(-)
>
>
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
On Mon, Jun 03, 2024 at 09:55:24AM -0700, Reinette Chatre wrote:
> Thank you to Andrew for picking up this series into the
> mm-nonmm-unstable branch. I am not familiar with how patches flow
> from this repo/branch but I expect that this inclusion will require some
> high level coordination between the big repos since resctrl changes
> usually flow upstream through x86/cache branch of tip and I
> anticipate some conflicts and also needing to figure out how to deal
> with this new dependency in planned resctrl changes.
Which is totally useless coordination if Andrew simply leaves x86
patches to go through the tip tree and there are no conflicts.
> Could you please provide your guidance on how to achieve a smooth
> upstream of this work?
I'd prefer if resctrl patches go only through tip so that there's no
unnecessary headaches with merging and coordination.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, 3 Jun 2024 19:01:06 +0200 Borislav Petkov <bp@alien8.de> wrote: > > Could you please provide your guidance on how to achieve a smooth > > upstream of this work? > > I'd prefer if resctrl patches go only through tip so that there's no > unnecessary headaches with merging and coordination. No probs. If/when patches turn up in a different tree (or get convincingly nacked) I'll drop the mm.git copy. I'll drop these now as things appear to be in hand.
On Tue, Jun 04, 2024 at 07:22:50PM -0700, Andrew Morton wrote:
> No probs. If/when patches turn up in a different tree (or get
> convincingly nacked) I'll drop the mm.git copy.
>
> I'll drop these now as things appear to be in hand.
Cool, thanks.
In general, you can safely ignore arch/x86/ patches. We're usually quick
to pick them up when ready. Getting them properly reviewed is a whole
another story... :-\
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
> I'd prefer if resctrl patches go only through tip so that there's no > unnecessary headaches with merging and coordination. The two resctrl patches depend on the patch to <linux/cacheinfo.h> So you'd need to take that patch through tip x86/cache as well. -Tony
On Mon, Jun 03, 2024 at 05:18:37PM +0000, Luck, Tony wrote:
> The two resctrl patches depend on the patch to <linux/cacheinfo.h>
> So you'd need to take that patch through tip x86/cache as well.
Sure, as it is usually done.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2026 Red Hat, Inc.