On Wed, Dec 07, 2022 at 02:53:58PM +0200, Tariq Toukan wrote: > > > 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? I've got bitmap tree and can move it there, but this series is related to scheduler and NUMA as well, and I'd prefer move it in those trees. If moving through bitmaps, I'd like to collect more reviews and testing. Thanks, Yury
