Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp702245ybz; Wed, 15 Apr 2020 17:04:03 -0700 (PDT) X-Google-Smtp-Source: APiQypJtOQCNfFQKRmvT7sBOMXlRNoK4VWQ7OU8YLjOxFgNwY80jHIBu+5Q95iUdaWCZy8TVn0Op X-Received: by 2002:a50:c20a:: with SMTP id n10mr28288709edf.319.1586995443660; Wed, 15 Apr 2020 17:04:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586995443; cv=none; d=google.com; s=arc-20160816; b=Gr9s7QUu/r/w4Rppynaol43WZj81Elw5h6hw8aV8ah/noUrk7SOMJQ2akLLoQjfGQa pn+bB0HWyv0A3EdH1glgWR7gi3A65xqEN8Cgt6ByazXHHdskrPNHu/6SfDSQ2Fo+dOJl WxkYwjUIUpQOyZMmpVCmdtT3b/xxrT0PYuQqwhWyV/pVI+C2FTy3OLma8oCNiuqBzIwI ektTY8YAAIYwR4q59D2LZN3CBa0zuX5nzfygb8qPwxtMXsdBJaQJqtAoHSjKAW70OzLb 0fbsS3ZGFRAg6AeJd8RRrv+ZusSymUlvXAZGhpqZTCr7l1wHFpB6dAUMEJubJCfPujbY Sdsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=O7QWjKpDAcS01HFPr661y/KVnSpx8h+aY6SEVswBaSc=; b=XgMCYJIKGddcRudtpJtCS3+imYlMwGKEDNIriEu8EVZg3IYOy1OfFJMkMm4z2e/Xc4 cgzCa5dzOwm0GCdYE0L74MTZIXsyyLBPTfMI+ch+f1bh0yJ0uzff25TcRSt7aXZdR8SD F5RxKBH6jU78RLYvOW946Mg9inhH4OPs1atOzeaUShwPSlOf9Z4xQEd8RvIh3wWaq2Ff zWiF1t0TnK54wH8M43NapWvSABZ8teL1UxQjF60fEUdGJs+wEKMoW/jMKvHftE4MFFbV vpGdStE+7uYkgJEtOGLDYEWQCt+Ke/RFrAfZ00Xre0AhiOQxQi7w9EwwV7GsQ+B2fbcX mPQA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d16si7748959edr.480.2020.04.15.17.03.40; Wed, 15 Apr 2020 17:04:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505448AbgDONTs (ORCPT + 99 others); Wed, 15 Apr 2020 09:19:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:56768 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S370786AbgDONSm (ORCPT ); Wed, 15 Apr 2020 09:18:42 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 83EFC20575; Wed, 15 Apr 2020 13:18:40 +0000 (UTC) Date: Wed, 15 Apr 2020 09:18:38 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Valentin Schneider , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Andrew Morton , Thomas Gleixner , Yury Norov , Paul Turner , Alexey Dobriyan , Josh Don , Pavan Kondeti , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq() Message-ID: <20200415091838.1555b45e@gandalf.local.home> In-Reply-To: <20200415093935.GA20730@hirez.programming.kicks-ass.net> References: <20200414150556.10920-1-qais.yousef@arm.com> <20200414162742.0ef4d9ee@gandalf.local.home> <20200415093935.GA20730@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Apr 2020 11:39:35 +0200 Peter Zijlstra 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 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