Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq()

[Steven Rostedt]

On Wed, 15 Apr 2020 11:39:35 +0200
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Tue, Apr 14, 2020 at 04:27:42PM -0400, Steven Rostedt wrote:
> > On Tue, 14 Apr 2020 19:58:49 +0100
> > Valentin Schneider <valentin.schneider@xxxxxxx> wrote:
> >   
> > > To move this forward, I would suggest renaming the current cpumask_any_*()
> > > into cpumask_first_*(), and THEN introduce the new pseudo-random
> > > ones. People are then free to hand-fix specific locations if it makes sense
> > > there, like you're doing for RT.  
> > 
> > Or leave "cpumask_any()" as is, and create a new "cpumask_random()" for
> > this purpose.  
> 
> Well, that's just twisting words, not sure I like that. 'Any' really
> means 'any'. So in order to preserve long term sanity, I'd vote for
> Valentin's approach of converting existing users over to first.

Well, to me "any" means it can be "any" and leaves it up to the
implementation to decide. Thus, "any" can always be the first one, or the
last one, or some random one. It means, "you don't care". If someone comes
to you showing you a deck of cards and says "pick any card". Picking the
first one every time is legitimate.

But saying "random" or perhaps better "shuffle" documents that you expect
something different each time.

I guess the best thing to do is to look at how they are used in the kernel,
and see if picking the same one (first or last) could cause issues. If all
the use cases really want something different each time, then great I
agree, let's make "any" give something different. But if the use cases are
"I don't care, just give me something fast" then I think we should leave it
as is. As the "random" version does add a slight overhead.

To me it comes down to documenting the use case. "first" means you really
want the first one. "any" would mean you don't care which one. "random" (or
whatever) means you would like to get something different each time.

How about calling it: cpumask_surprise_me().

-- Steve