Re: [PATCH 0/4] cpumask: add missing API and simplify cpumask_any_housekeeping()

[James Morse <james.morse@arm.com>]

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