Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp1507513imn; Sun, 31 Jul 2022 09:40:39 -0700 (PDT) X-Google-Smtp-Source: AA6agR69glY+PkVXMsJ8Pw5cwYipFIH1+jxHkGsrnixAUjS39J6Kp0FL3MD3qclp8ZF2r2AkuyvY X-Received: by 2002:a63:90c1:0:b0:41b:d351:f338 with SMTP id a184-20020a6390c1000000b0041bd351f338mr4744563pge.228.1659285639467; Sun, 31 Jul 2022 09:40:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659285639; cv=none; d=google.com; s=arc-20160816; b=vZnl7uXuxnKou9Qv3eaQU7Uczv4O83HKwEyzXUecLMwLv2W3X7csLsHKDLF0yA7GrL 1L9npSvu0/G7VBxINW7HfRVVzuhLfT3V/1p1kXS9+YIe0sqhiVWLZ2EUTblU2ujQcGgo 4edp7yY2CTC6n0dk/ihVQYQbyxZkaP5Zs2/K+85nMWfsuWwFNDTL3mYQjWtbpGPU7Sr+ SR3UvfsL1JZF26ZZP/gjQnw4FQU9Ds2+MjFyj5v45f4usAUGunSNCv2MFTLXSXdAjVAH peGiaA0YjXbRPE4ASoABwvGTTHKGRiMCqHq1UM9V1ZJYzKYWU3IF3Yps9+3pE3WV08LD JAmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=O5fzJKCKvnX543t55GLgI6tA3O4NIA7ad+898Ffse3w=; b=AZsyZol12t9vAQEFNsrInztU8bq5ValgpQ6BUnviHe52PLFAj/Xkzo64jXiNkbdSms 9pwfIdj2WNfU72jWjGwWuEFMWxv7BTZ1QuFoI2Q6R89ajNEUKVNPMtqS1FibGh/UrEEx JFVPlza5a+h4/WNd7f98rnVU4A5ZSF61BUJggA84tJXuFoNZz8+vjbMMcyF1sduNheR5 w30pAhOebDvxP6eS3QxKWFZu+LBDNAD0qIiz4xqGK9YSBm4P1WTRYug81qoydxbZp8SR INoSmfz8tl2WOES+mlfySj0Xoi2akeooxM5jbzKF/kSAWy6tQrQJgU/M/SmGlRQDixo8 G4/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Etnt1m5z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t23-20020a17090a5d9700b001f22106a50esi9980500pji.66.2022.07.31.09.40.22; Sun, 31 Jul 2022 09:40:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Etnt1m5z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237316AbiGaPnr (ORCPT + 99 others); Sun, 31 Jul 2022 11:43:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231424AbiGaPnp (ORCPT ); Sun, 31 Jul 2022 11:43:45 -0400 Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 240C6EE31; Sun, 31 Jul 2022 08:43:45 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id b7so5460624qvq.2; Sun, 31 Jul 2022 08:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc; bh=O5fzJKCKvnX543t55GLgI6tA3O4NIA7ad+898Ffse3w=; b=Etnt1m5zuKR7W4Ju2lEurqp8fzpduFBeky7nqg+H8/w99ulQw9mPGAZ88rMEYpUtvb DsG0wi5u/PVmZdn9ThPe6VK1eHEW/hLFuSNvnrJuw5ZR/Z8VH8U5V34UaxFwuUoJSbjq 5ot5k1jShAufGKZn255i7BVZXCHmnGNlfbC4GzO0kOkEyQkXLLVKK840QbSB833fH0+B JmpfOjY/w4k4dAe6n43y4gNc7pqipGhNRS1a6N9EWyknRMRVMB9nFJ1gbskQ7WzNkR+8 HJSg6zJy3/t7WBtS84D/VLLXp2CYZcg+KWhFKwn0XG2wmwYA0DdgXWGohm37kWU/Oem2 PZSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc; bh=O5fzJKCKvnX543t55GLgI6tA3O4NIA7ad+898Ffse3w=; b=yjmY1xs3UpOiMbtWVVCpB6drG37AKpf4JphExPJwregTW1xUzzNH0LIZSs1zTKUF17 INcmnQMnttIbez2MyLjWctRjpCnYJfxBCHxF0uyJaH0sbS2WKz4YtJHkXoW1ei4Q/Lyr X7SuPnNcDuLgI3eURKpSNce+beLLev1CKmRg/ulYnOikB1Vvj+PHrkayHiVC/bruX2JS x6LJhY8IBHOjozXveJlTmUI3Ic9cxYW5mANa14A0m/qg51I5t0aewKJA1YXW+vqWCN8H oJc89K58ZBr0QlyxHJ9Qe3B9wMPR7bX1HGQA0VGeRf3lqw1+5qmzk/L1jS+DbRoCFLg8 RLdA== X-Gm-Message-State: ACgBeo2LzVPEqJxa5hOi8bIPdoeD9MlvR0YICn2BXifNUdC8RMPz+dIT EFWGDWAn+40RId5ZK/y3v3uZ1X/bOgM= X-Received: by 2002:ad4:5be6:0:b0:473:9831:541a with SMTP id k6-20020ad45be6000000b004739831541amr10912305qvc.118.1659282224233; Sun, 31 Jul 2022 08:43:44 -0700 (PDT) Received: from localhost ([2601:4c1:c100:1230:ac7a:fe76:f4fe:fa32]) by smtp.gmail.com with ESMTPSA id q22-20020a05620a0d9600b006b872b606b1sm5050082qkl.128.2022.07.31.08.43.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Jul 2022 08:43:43 -0700 (PDT) Date: Sun, 31 Jul 2022 08:43:44 -0700 From: Yury Norov To: Sander Vanheule Cc: linux-kernel@vger.kernel.org, Andrew Morton , Andy Shevchenko , David Howells , Ingo Molnar , Geert Uytterhoeven , Jonathan Corbet , "Kirill A . Shutemov" , Matthew Wilcox , NeilBrown , Rasmus Villemoes , Russell King , Vlastimil Babka , William Kucharski , linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 06/10] lib/cpumask: move trivial wrappers around find_bit to the header Message-ID: References: <20220706174253.4175492-1-yury.norov@gmail.com> <20220706174253.4175492-7-yury.norov@gmail.com> <9383b9b62a15ba6f91af5adb0b0b1dd90ac1a3df.camel@svanheule.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9383b9b62a15ba6f91af5adb0b0b1dd90ac1a3df.camel@svanheule.net> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 31, 2022 at 11:42:52AM +0200, Sander Vanheule wrote: > Hi Yury, > > On Wed, 2022-07-06 at 10:42 -0700, Yury Norov wrote: > > To avoid circular dependencies, cpumask keeps simple (almost) one-line > > wrappers around find_bit() in a c-file. > > > > Commit 47d8c15615c0a2 ("include: move find.h from asm_generic to linux") > > moved find.h header out of asm_generic include path, and it helped to fix > > many circular dependencies, including some in cpumask.h. > > > > This patch moves those one-liners to header files. > > > > Signed-off-by: Yury Norov > > --- > > ?include/linux/cpumask.h | 57 ++++++++++++++++++++++++++++++++++++++--- > > ?lib/cpumask.c?????????? | 55 --------------------------------------- > > ?2 files changed, 54 insertions(+), 58 deletions(-) > > > > diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h > > index 760022bcb925..ea3de2c2c180 100644 > > --- a/include/linux/cpumask.h > > +++ b/include/linux/cpumask.h > > @@ -241,7 +241,21 @@ static inline unsigned int cpumask_last(const struct > > cpumask *srcp) > > ????????return find_last_bit(cpumask_bits(srcp), nr_cpumask_bits); > > ?} > > ? > > -unsigned int __pure cpumask_next(int n, const struct cpumask *srcp); > > +/** > > + * cpumask_next - get the next cpu in a cpumask > > + * @n: the cpu prior to the place to search (ie. return will be > @n) > > + * @srcp: the cpumask pointer > > + * > > + * Returns >= nr_cpu_ids if no further cpus set. > > + */ > > +static inline > > +unsigned int cpumask_next(int n, const struct cpumask *srcp) > > This also drops the __pure speficier for these functions. Since I have a patch > that does the opposite for cpumask_next_wrap() [1], I was wondering what your > reasoning behind this is. > > Since a cpumask like cpu_online_mask may change between subsequent calls, I'm > considering to drop my patch adding __pure, and to follow the changes you've > made here. > > [1] > https://lore.kernel.org/all/06eebdc46cfb21eb437755a2a5a56d55c41400f5.1659077534.git.sander@svanheule.net/ __pure is a promise to the compiler that the function will not modify system state (i.e. will not write into the memory). Now that the cpumask_next etc. became static inline, there's no reason for the hint because the compiler inlines the code, and there's no a real function. Maybe then it's worth to propagate the __pure to find_bit() helpers... Would be great to get comments form compiler people. Rasmus? Thanks, Yury