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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C889FC00140 for ; Sun, 31 Jul 2022 15:43:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B16F58E0002; Sun, 31 Jul 2022 11:43:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC6B08E0001; Sun, 31 Jul 2022 11:43:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98DED8E0002; Sun, 31 Jul 2022 11:43:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 882318E0001 for ; Sun, 31 Jul 2022 11:43:45 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 60DA11A0219 for ; Sun, 31 Jul 2022 15:43:45 +0000 (UTC) X-FDA: 79747815210.24.89C0F83 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf24.hostedemail.com (Postfix) with ESMTP id 1527F180016 for ; Sun, 31 Jul 2022 15:43:44 +0000 (UTC) Received: by mail-qv1-f47.google.com with SMTP id q3so6831758qvp.5 for ; Sun, 31 Jul 2022 08:43:44 -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=pR/c21a5SA9MSFWj1yzQdw9i4tBMjW/yvGMW9RyDOIuHKAkSPIkatjIYPqCP9qQ5lk 2wk6bcM2FVamrQdEEn+ZVkPv+uviV5vSjulboUCph95wbYilVLX4iIXi48ro9uRTRECB qHEdo2zFpDfMvP0EcmmWdy8YWuYEm3T2Mj//6ir95Qa50vR0XOvoy06Tz/XRror9Xy7c yQ+PdJpb0FNT5/rocZEJp+ZnpSXyYLp5JUGCn9ldXYJlctnlun5p/2DYo3vy91AVr+An 5F8I/9Cskyl2eTgD0bafdIrP5I8TIHVGzZ31s8A08Kf3Pqziytf9a8TaR9pkRLFbyG4f OiIw== X-Gm-Message-State: ACgBeo04QDDgqlG0r9hgfQxPKSQ/YFvW5+hBgSSE13TMCok/NFGXTg3L sZ4GtnQjDLI7+DKXQxYP6uE= 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-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9383b9b62a15ba6f91af5adb0b0b1dd90ac1a3df.camel@svanheule.net> ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Etnt1m5z; spf=pass (imf24.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=yury.norov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659282225; a=rsa-sha256; cv=none; b=WDlkj9GdQYqzQcHC2fV90SiohR//1wDA82Y211qxnuCBvb0XXsD98pcQQ2pUO5MaQ5I9TV i+/LVa6vT+N6SIf0mQ75ZMsM3wh1zKykf4YYc8yW/FDpUG3PhwK598G3o8oMHHKj7FWBgG E1w0ELS4PKmbsgSXaa74irW5HeeCCCc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659282225; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=O5fzJKCKvnX543t55GLgI6tA3O4NIA7ad+898Ffse3w=; b=PVARiTLDEpvFSMwSZ3XSSltQH8jpOHKaARy6yWM4b7hcPWg+Mahj+5+OBNJNmH3sPV5PBN rUjHz2SIweQJUiINs8W9Ko8o0FbEZVgWy9UuJnZ/Tqoscrjm9NoPvEOvm5uY3zNRW/AINA Ur04a+voIVhiRWIvLmSwWaYaTnGsqI8= X-Rspamd-Queue-Id: 1527F180016 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Etnt1m5z; spf=pass (imf24.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=yury.norov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspam-User: X-Stat-Signature: fr7h7m3rd44ojnqpf3hytoiektc6ss3c X-HE-Tag: 1659282224-259777 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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