From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C1E86C00140 for ; Sun, 31 Jul 2022 15:45:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KsnRcxBiIwfxGcY56hVHagnp/NaKuOfiHgIlhwoecLU=; b=Qr3dWRlf5kM+ZZ yDnXcDz/K0qhjMBR0X8Yv/05kgW5H4clERWgrlUFW7XOyalCz+t8ktlC3xYxsKMX5+QdF9GqZs8Vq f7i3IUZ/lIIj8Kwr4metZhIe3Uspeg/bnUomgucNQ85/H3eN8MTRa/GSS3RdjSo2oefAa9vBBKad4 dGdnmOq8FxA5dSlKiWN3BDSyT00tQVvmcC7cjOjgo9kCfQK/yeCMvVy1txhofroAwBW1s5ZlreEBX F4s1aYK84a7KIxW/DSReblfWg8KIUTo8ZxylF9SZhPpRzUmZTAvoAN04mcIsgfvbdmyDQGpI6LixT 0OaxVRmY+mc41XpvbkVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oIB6a-00DqFX-IB; Sun, 31 Jul 2022 15:43:48 +0000 Received: from mail-qv1-xf34.google.com ([2607:f8b0:4864:20::f34]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oIB6X-00DqDZ-KE for linux-arm-kernel@lists.infradead.org; Sun, 31 Jul 2022 15:43:47 +0000 Received: by mail-qv1-xf34.google.com with SMTP id i4so6812567qvv.7 for ; 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=6PruqjY2Ykbtp8EpZhIVYN/TskcArwVAyEhkdBw6dxJ9qqwsTWp+9DbndiBAyWskYw ABlp7iHHCVEB7C4VKEpqAahgM0l/QydyChq4EQRDE48ybnlUkMonUtJka/IX0g/7wLQO EJugBYuwttUyEMzcjg1nrP96DD5d0NTmhrlI6PgPPL/lmu3CjmvTle8oGtaPzkUEMYaO iUG93mXBNHgik2grZPRki4iaP0QmpY6q2EBWdHxZ45cXhfWGC8qczhLAwDDx8jI+QhuZ f1DOPIhse9yUvmsZkOPIh5XqC+W/lZpZWXpOaxqcS0ywAeBDN0tidPEd4RO3FY0lyNxW fQWg== X-Gm-Message-State: ACgBeo0T7ef3hyOMV9Vz0+NnN4Gi5YJLBBIDnOmq7ebSJ1wuzRtDK97L 9IT1n3gnbfUMAjMfn4vz/Iw= X-Google-Smtp-Source: AA6agR7nm+uPqXgj2bad1CM22NDQbm1CSaTYIGyvrjFVHd9F581P1hgO8deF0JcPA9ncVixpciPiKw== 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-Disposition: inline In-Reply-To: <9383b9b62a15ba6f91af5adb0b0b1dd90ac1a3df.camel@svanheule.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220731_084345_710430_0D1C5C43 X-CRM114-Status: GOOD ( 26.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 f= ix > > many circular dependencies, including some in cpumask.h. > > = > > This patch moves those one-liners to header files. > > = > > Signed-off-by: Yury Norov > > --- > > =A0include/linux/cpumask.h | 57 ++++++++++++++++++++++++++++++++++++++-= -- > > =A0lib/cpumask.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 55 -------------------= -------------------- > > =A02 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 stru= ct > > cpumask *srcp) > > =A0=A0=A0=A0=A0=A0=A0=A0return find_last_bit(cpumask_bits(srcp), nr_cpu= mask_bits); > > =A0} > > =A0 > > -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 >=3D 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.1659= 077534.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel