From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 D6ECC19CCFA for ; Fri, 17 Jan 2025 16:32:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737131529; cv=none; b=ItLHunigESN3hSx/z1lLWkVPScOm/uNs5llwfc4UqdrF/erYfxwimSN0V8gBB3GmTmT+NowQVyZt1SLIgcmc96m4DseWoJ7RGLGOYcNMo3SwCPnDKsSFmjp72FlOscbl/rGvuatA6kBwNeUfFRAsCrIkL3HX/lXhI866LHuNatU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737131529; c=relaxed/simple; bh=3MKOZjVPfO7Ojb5rmIzMq03tp2O9cqA9SsZupnPaXQM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FpYglgrNKOSKCu5lOrmWJ7xGrAoXTxxChTzO3xvciMjQqknBaFfqpTPuUbhiDspjpvYbMvSYuV3oKxR4Uu1aMsX0S9awbWCqs0IwK9eDkfvn0lKdxxNAxz0OQmSnJzKcjgILEAfWjj5icwQeaDLflZJBUSyi3J6PdsTRk6YDVuY= 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=BXJ3lm3k; arc=none smtp.client-ip=209.85.214.182 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="BXJ3lm3k" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2166651f752so55939685ad.3 for ; Fri, 17 Jan 2025 08:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737131526; x=1737736326; 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=KtiyW5nfCCFnHdFnuMJNzFFdIdTH2fvFuQ19FLyOYos=; b=BXJ3lm3kAyOJHW46GqnHqwCBtKVktD0W/wrbyeDbkLhxI4BTm4dR8pvPbJsl0/AJR9 GVCgM2dxvloSBDcts39JIlvbpg2Q6CWCFyLLckqMzWWqUOmS8oqYR4bJkDLflWLnXM1S OAtgTEHWvXL7I6TSnZhhEtot67VlROzux5N+hLLudNUNwR66O85kjuf40xi9NMhl1W+9 EPut+x572xiv9NSRzIVAwH8Z616HmH1VEZOXZqdeEroFw8NfDe3WPVs8CeHZzKCI9klV HEJrTZS0USgrYiKpapfcI/sA7jVxg21KZTJNvtM33Yx0oFNMDFRVhcnj+VCyAMgq3ScV 0VCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737131526; x=1737736326; 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=KtiyW5nfCCFnHdFnuMJNzFFdIdTH2fvFuQ19FLyOYos=; b=RMASZCCd83Jt7DYEW0PNUohcdOtEniqzkh80jUaPnJkAKfCU9YkHFpje1itVA8/h4y VBVo2/gw7IQ2D1xRzM/QDkJNjFnXa0RkdDF+pjvxeHiVivihJfvdm3OskClAPEfkI4TY clxpOL+AOeY47WgfAAIXuRKPwbGaFQm1OGh49lpP0CqGMMg7ihuRKnLRqQwaIO63fL2g uCo/yAiLShFWBhT0s/A94Zw42xvtJNh1mToAHroJu0fKnYBSOwPNNgcd6EBFdCemIcHm IMB1d1tlPodjc0suwkfOyyq2THwqk9pm/c53/Vf1/eT36PkU2BI47231VcsiWTJfF4Ag tUmg== X-Forwarded-Encrypted: i=1; AJvYcCWq4Kp3YBRILaMFeQuqK2vDte5pi7A8lL1tFngWsYqccdBv5Rg+lOyQ4zewtfuy+8mleKqp0J7ojky3ZsI=@vger.kernel.org X-Gm-Message-State: AOJu0YwLYr1OXKbFe7zQWNnHE+aSTCZVKmPod/zTO89baGiNaivO8GyH qAyxrAu02pkfAKw6rwlD05XZFImK3d7eEWczQP6CEpzQNKP00ILb X-Gm-Gg: ASbGncuQlVuf5uIcIBRb3W6Z2a+rS4meXzwSy8quLo4P3CzM9mAyc8aLNd5lRY9BS/4 ON3pV6PPyKUuetPwZY3tA62iY1TUH5H3SrZkCDO02QnibN5QRZuqJ7RsiLVIGqLXmHjP9z2qbf5 Lez0mGLsSzMaBvakIf/zXhb26Y3E8nfY7mSL+qdpryKTX45pSWvKR1yWVWqBptE3DWo5bTS5ksD LGyMsWw0bP5Ft5gsgf6zYmkLKpyL54cduVUgwlXGEZKEdIo03PeCO8Z20oSmHJrGycWuTnI8YqR 6k7CPbgI X-Google-Smtp-Source: AGHT+IETMs3lz+UA1IWqRkcbJ/cTHHNMmytz6xqTaXYXdaw5oidw01dJXc37aFfYwaS3HKAjTZRs1Q== X-Received: by 2002:a05:6a20:4321:b0:1e1:afa9:d397 with SMTP id adf61e73a8af0-1eb2147ebebmr4397311637.15.1737131525975; Fri, 17 Jan 2025 08:32:05 -0800 (PST) Received: from visitorckw-System-Product-Name ([140.113.216.168]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-a9bdd30d1fdsm2068919a12.60.2025.01.17.08.32.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2025 08:32:05 -0800 (PST) Date: Sat, 18 Jan 2025 00:32:01 +0800 From: Kuan-Wei Chiu To: I Hsin Cheng Cc: yury.norov@gmail.com, linux@rasmusvillemoes.dk, jserv@ccns.ncku.edu.tw, mark.rutland@arm.com, linux-kernel@vger.kernel.org, eleanor15x@gmail.com Subject: Re: [PATCH] cpumask: Optimize cpumask_any_but() Message-ID: References: <20250117142658.297325-1-visitorckw@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 Fri, Jan 17, 2025 at 10:59:31PM +0800, I Hsin Cheng wrote: > On Fri, Jan 17, 2025 at 10:26:58PM +0800, Kuan-Wei Chiu wrote: > > The cpumask_any_but() function can avoid using a loop to determine the > > CPU index to return. If the first set bit in the cpumask is not equal > > to the specified CPU, we can directly return the index of the first set > > bit. Otherwise, we return the next set bit's index. > > > > This optimization replaces the loop with a single if statement, > > allowing the compiler to generate more concise and efficient code. > > > > As a result, the size of the bzImage built with x86 defconfig is > > reduced by 4096 bytes: > > > > * Before: > > $ size arch/x86/boot/bzImage > > text data bss dec hex filename > > 13537280 1024 0 13538304 ce9400 arch/x86/boot/bzImage > > > > * After: > > $ size arch/x86/boot/bzImage > > text data bss dec hex filename > > 13533184 1024 0 13534208 ce8400 arch/x86/boot/bzImage > > > > Co-developed-by: Yu-Chun Lin > > Signed-off-by: Yu-Chun Lin > > Signed-off-by: Kuan-Wei Chiu > > --- > > Not sure how to measure the efficiency difference, but I guess this > > patch might be slightly more efficient or nearly the same as before. If > > you have any good ideas for measuring efficiency, please let me know! > > > > include/linux/cpumask.h | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h > > index 9278a50d514f..b769fcdbaa10 100644 > > --- a/include/linux/cpumask.h > > +++ b/include/linux/cpumask.h > > @@ -404,10 +404,10 @@ unsigned int cpumask_any_but(const struct cpumask *mask, unsigned int cpu) > > unsigned int i; > > > > cpumask_check(cpu); > > - for_each_cpu(i, mask) > > - if (i != cpu) > > - break; > > - return i; > > + i = find_first_bit(cpumask_bits(mask), small_cpumask_bits); > > Hi Kuan-Wei, > > How about using cpumask_first(mask) here to keep better consistency? > Sure. > > + if (i != cpu) > > + return i; > Wouldn't it benefit abit to check "i >= nr_cpu_ids" prior to > find_next_bit() ? if "i >= nr_cpu_ids" holds it would be a waste to > perform find_next_bit(). > Hmm, adding this check increases the image size back to what it was before the patch. Also, it only saves the execution time of find_next_bit() when the cpumask is entirely zero. I'm not sure how often a fully zero cpumask actually occurs in practice, but if we assume a uniform distribution, the probability of this case would approach zero. Regards, Kuan-Wei > > + return find_next_bit(cpumask_bits(mask), small_cpumask_bits, i + 1); > > } > > > > Regards, > I Hsin > > > /** > > -- > > 2.34.1 > >