Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3748918ybz; Mon, 20 Apr 2020 08:45:50 -0700 (PDT) X-Google-Smtp-Source: APiQypLL0+vvqcRFu9vbonUDPNil0uKHq7pxUn61bVtwXVNUyRswyaJqfPIZUqeOcZNM0/1BZBWq X-Received: by 2002:a17:906:3443:: with SMTP id d3mr17344592ejb.18.1587397549834; Mon, 20 Apr 2020 08:45:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587397549; cv=none; d=google.com; s=arc-20160816; b=m38bjdt06TJWHO+WfedcX3Yrjtmj59jmxxCpGQoDMDskR/Upcg2QZQp9rFRcFuiFNy opozQncoAIitR1S6lPNXuHgJ/tuJwg9X5bYPb6lvWBXtKETJW0lm3u4+UAlBAT7eu0QY uoA1oMzBm4ObZvJ/CL6xiwl2HLcwNWTCYfvVcKfBygt4EPNQ4lOkTRO9CX+eihzfmnsW F21IUg91MppPAdi878TltxJmTIRNrrxyg08/QlrIfq7TAH2ve/KotIGQq/xumiNjt/31 asiRGmCqWdI2aecA29+hcwTdBUAmQfgQpFkY0mGGEdyUlM/KdzasCEAy4nq4P2RZiwOi K67Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=icNs4uTty+kTGAcERpzqzd5zkQv+5Q6aNDLF6nLTKgY=; b=J+SADkpD8ah3uDndrK1MtNoAkMZVIQpMcuNJtADB359vh2VdeyL3SbCmXBwVLt4sEM rYdXmKmmdAuX+WWWjZ+OhC42zjLdM0k6H3prjv6XLBohqmjUZt2OXxGzaq4viyV8jrRh 6Wdlb9dIeB4YI05QgTd3BtY2mSgbbu9urJNyeLAGYELOX2cFU48mEixw9k9oEaxH4OBy 40fmr/woFrRr4aksbZIAGNecVlcxcusZhVasMC8iEn6nHv5dTiKMP76+wSUcv4C5vLcE xm9vbYLn0e287l/VT2A8TKFrHQvh1BlH9p6buuElTS1LmJHyE23dUrx9QsJ4vhefCGJ6 7NdA== 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 bz1si757192ejc.368.2020.04.20.08.45.26; Mon, 20 Apr 2020 08:45:49 -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 S1728303AbgDTPnX (ORCPT + 99 others); Mon, 20 Apr 2020 11:43:23 -0400 Received: from foss.arm.com ([217.140.110.172]:51306 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbgDTPnX (ORCPT ); Mon, 20 Apr 2020 11:43:23 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9017F31B; Mon, 20 Apr 2020 08:43:22 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 74FBE3F73D; Mon, 20 Apr 2020 08:43:20 -0700 (PDT) Date: Mon, 20 Apr 2020 16:43:18 +0100 From: Qais Yousef To: Peter Zijlstra Cc: Steven Rostedt , 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 2/4] cpumask: Make cpumask_any() truly random Message-ID: <20200420154317.klwoztvdybmvykwe@e107158-lin.cambridge.arm.com> References: <20200414150556.10920-1-qais.yousef@arm.com> <20200414150556.10920-3-qais.yousef@arm.com> <20200414121956.3687d6e9@gandalf.local.home> <20200415093617.GZ20730@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200415093617.GZ20730@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/15/20 11:36, Peter Zijlstra wrote: > On Tue, Apr 14, 2020 at 12:19:56PM -0400, Steven Rostedt wrote: > > > > +/** > > > + * cpumask_any - pick a "random" cpu from *srcp > > > + * @srcp: the input cpumask > > > + * > > > + * Returns >= nr_cpu_ids if no cpus set. > > > + */ > > > +int cpumask_any(const struct cpumask *srcp) > > > +{ > > > + int next, prev; > > > + > > > + /* NOTE: our first selection will skip 0. */ > > > + prev = __this_cpu_read(distribute_cpu_mask_prev); > > > + > > > + next = cpumask_next(prev, srcp); > > > + if (next >= nr_cpu_ids) > > > + next = cpumask_first(srcp); > > > + > > > + if (next < nr_cpu_ids) > > > + __this_cpu_write(distribute_cpu_mask_prev, next); > > > > Do we care if this gets preempted and migrated to a new CPU where we read > > "prev" from one distribute_cpu_mask_prev on one CPU and write it to another > > CPU? > > I don't think we do; that just adds to the randomness ;-), but you do Yep we don't care and it should enhance the randomness. > raise a good point in that __this_cpu_*() ops assume preemption is > already disabled, which is true of the one exiting > cpumask_any_and_distribute() caller, but is no longer true after patch > 1, and this patch repeats the mistake. > > So either we need to disable preemption across the function or > transition to this_cpu_*() ops. Sorry wasn't aware about the preemption check in __this_cpu_write(). Transitioning to this_cpu_write() makes sense. Unless Josh comes back it'll break something he noticed. Thanks -- Qais Yousef