On 11/30/2022 3:47 AM, Yury Norov wrote:
On Mon, Nov 28, 2022 at 08:39:24AM +0200, Tariq Toukan wrote:
On 11/17/2022 2:23 PM, Valentin Schneider wrote:
On 15/11/22 10:32, Yury Norov wrote:
On Tue, Nov 15, 2022 at 05:24:56PM +0000, Valentin Schneider wrote:
Is this meant as a replacement for [1]?
No. Your series adds an iterator, and in my experience the code that
uses iterators of that sort is almost always better and easier to
understand than cpumask_nth() or cpumask_next()-like users.
My series has the only advantage that it allows keep existing codebase
untouched.
Right
I like that this is changing an existing interface so that all current
users directly benefit from the change. Now, about half of the users of
cpumask_local_spread() use it in a loop with incremental @i parameter,
which makes the repeated bsearch a bit of a shame, but then I'm tempted to
say the first point makes it worth it.
[1]: https://lore.kernel.org/all/20221028164959.1367250-1-vschneid@xxxxxxxxxx/
In terms of very common case of sequential invocation of local_spread()
for cpus from 0 to nr_cpu_ids, the complexity of my approach is n * log n,
and your approach is amortized O(n), which is better. Not a big deal _now_,
as you mentioned in the other email. But we never know how things will
evolve, right?
So, I would take both and maybe in comment to cpumask_local_spread()
mention that there's a better alternative for those who call the
function for all CPUs incrementally.
Ack, sounds good.
Good.
Is a respin needed, to add the comment mentioned above?
If you think it's worth the effort.
No, not sure it is...
I asked because this mail thread was inactive for a while, with the
patches not accepted to the kernel yet.
If everyone is happy with it, let's make it to this kernel while possible.
To which tree should it go?
Thanks,
Tariq
