From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 113B221ADAB for ; Mon, 13 Jan 2025 11:09:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736766599; cv=none; b=RxuNrK+joaTbWwHBkbubw35y7w48L4hnePiUO6T5CU2naiKGs+N8+ZyWJrWWbI1lT6cShtseTFRxpjt9U0CLad2e0Yg3NslDhl26jlNNNrPFfs0QsTXBwCJW+sc139BWHTtZziXPfKD5use9uWRMkChcyIcHhKI1Qe/w6kj6eAk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736766599; c=relaxed/simple; bh=qLlA3w/4a/6mkhtQ+fzHNSM+YVWsZlbXAfFwmUvLt4Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RDcsU6IKCoIWNdkTh6jHZCdRwIb8U/a5LnUNkxefCvXEaxKlDKogaOy53gSo5h4lEZce3iRN8iqO3HPhOCD9Ep+wCAkmYaUwrXvSCyTmuhjHh4t21Vwn2LjJOd7j6FpNEIvZjWzZ5DtGUPuhGCa4icv+1t5K5jihfLOopHEcnw0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SZYDCQ/5; arc=none smtp.client-ip=209.85.216.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SZYDCQ/5" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2ef6c56032eso5187443a91.2 for ; Mon, 13 Jan 2025 03:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736766597; x=1737371397; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=DMATwRbV6o4ENAr0jx0IyNKi7Pb3ek+hEvnO4HQS5KQ=; b=SZYDCQ/5elwyGp19l6Oe09MmJwGcU8BtwQn+eqRrBJjb9rdRU6MFdHGVy4V5NbYnU0 asZTj+27etYllynp1Jrz+yGvezPEu7O49VS94pz/c1VlI8gg+6aKi1XDk1qZD8fuwIvf qYtzber0GRNS02plB8gFVT5WFSx3oOKDxDZLwJr6lT6Aumy8pIiWWY7n7YB2wYoyeTSx HVor4HOUce8LgSDalEgq52ola9FHUyWRsjNH7UFcA1euScLQlZkf6IpJUC3tsziGxV+0 GDmKzjUlyqPawi47UFRhp9Clgv2W9BefU8hwO+w6mKkAxuhYWbcitf+20C7/TcU7lB8B NDbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736766597; x=1737371397; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DMATwRbV6o4ENAr0jx0IyNKi7Pb3ek+hEvnO4HQS5KQ=; b=SXtz+tO4hc6QXxCRwSMD2uMwbZk1xFTjVYHduFxVhkL98ZdYP/oCnsG0s68uT9fqB+ y+YvK96HfOCHT/Zy+Bmh6nkG2SAdU8aRf9i0eVYcqCh9eUmDNVbCrn/d289pH5/Q8drT 4fKz49eaY2Z9Q2XsdB1MYNPAtHR3lFE+kj5mNgfOMg6I882CBnxA8QNJJOFNOspflYE8 dM6p3Z0MGmVWVJ2AHRMTstMZ0nfXbpnUk0hKCO4QycK4UTslv1TRJs415yquf+uXvZ1B jwUNDEjBSrg/xIGmHp3pi4FAstlOx92dD8/I6dCr0UluEIm2RZHsbva+crWm5+eFgl6N 09iA== X-Forwarded-Encrypted: i=1; AJvYcCWO3d3RvxU8v4TJbnraM72f0IO++CR9Zhb8vH+oCeosqB7pmEZsnrmXGZN9AjzXoYFc8qsaoFyNEGot4hM=@vger.kernel.org X-Gm-Message-State: AOJu0YyLcxzZRfFaOKwrqQF6uMA/WO2WQTDmkPa9/1yJQ10ESHigQ6ST 1d5jtpS1OU+aQmpLLZYYmV8NpdU4P1sMF0eXqJb/xL3vhjiufQRP X-Gm-Gg: ASbGnct9mLLMacht9azSIDX0QjvL4IWr4mrN1ZQ5wUoPEygnpqZo2jwmx8IJBnWN59p 0N98j4I1CEgjaznxfeA8m0aEabNjtfWHmec5zE+w6FGT5aS++eZA9kFuenCGWAwXER6hcCr0wZv wtmzpYYbrsNkGEBaodEorsLu02YTBmza4mBCKr2v327/FRPlHdbe0wJnSvKPYNwpzt1LYQKosFQ e6zs7EIBAR0LccIyVgjn8mcHd7mnO7VB5VeyVVmF5ntSNWqd5gE6lj27P48Rr306HzuVW0sjeZl uxf1+Ri7 X-Google-Smtp-Source: AGHT+IEddATJjc1MnbaG/SxNZ750d9zyDZ5pTLLSYUnqythfHfBIekyQWFeWhH8vBTZsbr3PgKxysA== X-Received: by 2002:a17:90b:3a05:b0:2ef:2d9f:8e55 with SMTP id 98e67ed59e1d1-2f548edaa0emr32861009a91.17.1736766597254; Mon, 13 Jan 2025 03:09:57 -0800 (PST) Received: from visitorckw-System-Product-Name ([140.113.216.168]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2f54a34dbb6sm10803709a91.42.2025.01.13.03.09.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 03:09:56 -0800 (PST) Date: Mon, 13 Jan 2025 19:09:53 +0800 From: Kuan-Wei Chiu To: I Hsin Cheng Cc: yury.norov@gmail.com, linux@rasmusvillemoes.dk, jserv@ccns.ncku.edu.tw, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] cpumask: Implement "random" version of cpumask_any_but() Message-ID: References: <20250113061839.22131-1-richard120310@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jan 13, 2025 at 06:27:26PM +0800, I Hsin Cheng wrote: > On Mon, Jan 13, 2025 at 06:13:07PM +0800, Kuan-Wei Chiu wrote: > > Hi I Hsin, > > > > On Mon, Jan 13, 2025 at 02:18:39PM +0800, I Hsin Cheng wrote: > > > Original implementation of "cpumask_any_but()" isn't actually random as > > > the comment claims itself to be. It's behavior is in fact to select the > > > first cpu in "mask" which isn't equal to "cpu". > > > > > > Re-implement the function so we can choose a random cpu by randomly > > > select the value of "n" and choose the nth cpu in "mask" > > > > > This patch may slow down the efficiency of cpumask_any_but(). Are there > > any in-tree users of cpumask_any_but() that require it to return a > > truly random id, or benefit from such behavior? > > Hi Kuan-Wei, > > Thanks for your review ! Yes indeed it may slow down the efficiency > abit. > > However there are some use cases I think randomness is important > such as "dl_task_offline_migration()" under kernel/sched/deadline.c , > where the operation of cpu picking shouldn't favor certain cpu too much. > > Also "select_task_rq()" utitlize "cpumask_any()" to pick cpu, it doesn't > need to be perfectly random, but neither should it only favor certain > cpu. > > What do you think? > If a true random number isn't needed, could next_pseudo_random32() be used instead for better efficiency? I'm not familiar with the scheduler, but if there are only one or two scheduler use cases, would you consider creating a new cpumask_random_but() API and converting those specific cases to use it? In this case, the patch should also be CC'd to scheduler developers. Additionally, you should explain the benefits of this approach in the patch description. Regards, Kuan-Wei