arch/x86/kernel/cpu/resctrl/internal.h | 28 +++------- include/linux/cpumask.h | 71 +++++++++++++++++++++++++- include/linux/find.h | 25 +++++++++ lib/find_bit.c | 11 ++++ 4 files changed, 112 insertions(+), 23 deletions(-)
From: Yury Norov [NVIDIA] <yury.norov@gmail.com> cpumask library missed some flavors of cpumask_any_but(), which makes users to workaround it by using less efficient cpumask_nth() functions. Yury Norov (4): relax cpumask_any_but() find: add find_first_andnot_bit() cpumask_first_andnot resctrl arch/x86/kernel/cpu/resctrl/internal.h | 28 +++------- include/linux/cpumask.h | 71 +++++++++++++++++++++++++- include/linux/find.h | 25 +++++++++ lib/find_bit.c | 11 ++++ 4 files changed, 112 insertions(+), 23 deletions(-) -- 2.43.0
Hi Yury, On 07/04/2025 16:38, Yury Norov wrote: > From: Yury Norov [NVIDIA] <yury.norov@gmail.com> > > cpumask library missed some flavors of cpumask_any_but(), which makes > users to workaround it by using less efficient cpumask_nth() functions. For the series - with the unsigned/int thing Reinette pointed out fixed: Tested-by: James Morse <james.morse@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Thanks, James
+James Hi Yury, On 4/7/25 8:38 AM, Yury Norov wrote: > From: Yury Norov [NVIDIA] <yury.norov@gmail.com> > > cpumask library missed some flavors of cpumask_any_but(), which makes > users to workaround it by using less efficient cpumask_nth() functions. > > Yury Norov (4): > relax cpumask_any_but() > find: add find_first_andnot_bit() > cpumask_first_andnot > resctrl (sidenote: above list of patch subjects do not match the series) Thank you very much for doing this work. This simplifies resctrl code significantly. I do have a couple of comments that you will find in the individual patches. Regarding upstreaming I would like to propose that the upstreaming of this work be split so that resctrl changes do not go upstream via separate trees during this cycle. I am ok with delaying the resctrl portion of this work for a cycle. This is because we hope to include a huge change [1] to resctrl that includes the code modified in this series. Having these two changes meet during merge window will be inconvenient for maintainers involved. If you require a user to upstream these new helpers then another possibility is to upstream this work via the tip repo if that is ok with x86 maintainers so that that huge resctrl patch is created on top if this work. Reinette [1] https://lore.kernel.org/lkml/20250411164229.23413-18-james.morse@arm.com/
On Wed, Apr 23, 2025 at 02:27:46PM -0700, Reinette Chatre wrote: > +James > > Hi Yury, > > On 4/7/25 8:38 AM, Yury Norov wrote: > > From: Yury Norov [NVIDIA] <yury.norov@gmail.com> > > > > cpumask library missed some flavors of cpumask_any_but(), which makes > > users to workaround it by using less efficient cpumask_nth() functions. > > > > Yury Norov (4): > > relax cpumask_any_but() > > find: add find_first_andnot_bit() > > cpumask_first_andnot > > resctrl > > (sidenote: above list of patch subjects do not match the series) > > Thank you very much for doing this work. This simplifies resctrl code > significantly. I do have a couple of comments that you will find in > the individual patches. Sure, glad to see you like it. > Regarding upstreaming I would like to propose that the upstreaming of > this work be split so that resctrl changes do not go upstream > via separate trees during this cycle. I am ok with delaying the resctrl > portion of this work for a cycle. This is because we hope to include a > huge change [1] to resctrl that includes the code modified in this series. > Having these two changes meet during merge window will be inconvenient > for maintainers involved. If you require a user to upstream these new > helpers then another possibility is to upstream this work via the tip repo > if that is ok with x86 maintainers so that that huge resctrl patch is created on > top if this work. > > Reinette > > [1] https://lore.kernel.org/lkml/20250411164229.23413-18-james.morse@arm.com/ I can move all the patches with my branch (bitmap-for-next) if you ack the restcl part, or let resctl folks (you, I guess) take over the series. Or we can split it, so I'll move generic part myself, and you'll move the last patch. Thanks, Yury
Hi Reinette, Yury, On 24/04/2025 04:11, Yury Norov wrote: > On Wed, Apr 23, 2025 at 02:27:46PM -0700, Reinette Chatre wrote: >> On 4/7/25 8:38 AM, Yury Norov wrote: >>> From: Yury Norov [NVIDIA] <yury.norov@gmail.com> >>> >>> cpumask library missed some flavors of cpumask_any_but(), which makes >>> users to workaround it by using less efficient cpumask_nth() functions. >>> >>> Yury Norov (4): >>> relax cpumask_any_but() >>> find: add find_first_andnot_bit() >>> cpumask_first_andnot >>> resctrl >> >> (sidenote: above list of patch subjects do not match the series) >> >> Thank you very much for doing this work. This simplifies resctrl code >> significantly. I do have a couple of comments that you will find in >> the individual patches. > > Sure, glad to see you like it. > >> Regarding upstreaming I would like to propose that the upstreaming of >> this work be split so that resctrl changes do not go upstream >> via separate trees during this cycle. I am ok with delaying the resctrl >> portion of this work for a cycle. This is because we hope to include a >> huge change [1] to resctrl that includes the code modified in this series. >> Having these two changes meet during merge window will be inconvenient >> for maintainers involved. If you require a user to upstream these new >> helpers then another possibility is to upstream this work via the tip repo >> if that is ok with x86 maintainers so that that huge resctrl patch is created on >> top if this work. > I can move all the patches with my branch (bitmap-for-next) if you ack > the restcl part, or let resctl folks (you, I guess) take over the series. > Or we can split it, so I'll move generic part myself, and you'll move > the last patch. That would mean co-ordinating the order those get merged in, which is extra work for the relevant maintainers. The patch that moves all the code is easy to regenerate as this series doesn't add any new functions. Ideally any series touching resctrl in the same merge window would also go via tip - but it would also possible to rebase onto an immutable branch. (needed if bitmap-for-next also has dependencies/conflicts on these patches) I think its easier for the tip folk if I rebase onto this once as/when its got all the needed tags. Thanks, James
Ping? On Mon, Apr 07, 2025 at 11:38:51AM -0400, Yury Norov wrote: > From: Yury Norov [NVIDIA] <yury.norov@gmail.com> > > cpumask library missed some flavors of cpumask_any_but(), which makes > users to workaround it by using less efficient cpumask_nth() functions. > > Yury Norov (4): > relax cpumask_any_but() > find: add find_first_andnot_bit() > cpumask_first_andnot > resctrl > > arch/x86/kernel/cpu/resctrl/internal.h | 28 +++------- > include/linux/cpumask.h | 71 +++++++++++++++++++++++++- > include/linux/find.h | 25 +++++++++ > lib/find_bit.c | 11 ++++ > 4 files changed, 112 insertions(+), 23 deletions(-) > > -- > 2.43.0
Hi Yury, On 4/22/25 6:50 AM, Yury Norov wrote: > Ping? From the resctrl side this looks promising and I have been meaning to review it with more detail. It looks promising because, apart from simplifying the resctrl parts, it also looks like it may help to address some new resctrl [1] requirements. Thank you. Reinette [1] https://lore.kernel.org/lkml/da51ba61-4ff0-4db4-a55f-743f6a3ea7da@intel.com/
© 2016 - 2026 Red Hat, Inc.