Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp264820imm; Thu, 26 Jul 2018 03:12:56 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcqY3iuqEJtrpx/CHVUzLDWc1TUnhp9Et+GaCqcqTrngdHPQPHAlNg8x0qAuHhPsbvjXHFs X-Received: by 2002:a65:5c02:: with SMTP id u2-v6mr1329837pgr.304.1532599976850; Thu, 26 Jul 2018 03:12:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532599976; cv=none; d=google.com; s=arc-20160816; b=cuET1h7627029wTrGnuTu0pJa3z0E/cHGGvuEhTExuNHt6f3a5wG0jTOUE+ZS7IEQA lT9MyWEvdPtOhKbTtWjgZn4r1dX3S2JJPUb1BLpII1Dq3fGIvGK27YVOFZYjDqXIS4gi bCMdQJFQH0POyaSdx1XIXPvMR0JC/ymiwe5vusHt0AjZhTOjjouJ+Rramy8cm/2dcrMi S8A0tMW7vuIBSOU4HjzOc9vFB2OYraMVJUC0JWCUQM+yT1LqJsCwUmhsglAvGLXe3Ayt VOdZLT05Z5EaJXVm1upUl2K/i/epud9vxNvZAzR+XtIF0s/RvUB44Hv0NXYuLXRh3npr Opkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:arc-authentication-results; bh=MFnaVorNo7ktpMTtlb2l92XdAgKBuXc3uZeK9ZtRo7Q=; b=Oyu3Y5XaI6IveNfxrky1lNzJ1xUxXhPjRP9RwSc+xoRqkdrXh+3qtYxLMdQ9zrUZR2 VODMXXiBOEP8YQeJOma2hExTaePiz3d8Jv7J1l5eEUm8vfvtSxo9zeYIolbXdH3MHFB2 FXjjWy4IgJGe3tAYamHsAECsf976SThfHvHg88FWxpVfpn5VcysMyQy2o7HrprIV2YDn ETKsXPN5SLfjqHDB2rC24HBQhdP6o17wj3Zi/ryewxorTO7ArFrOn6pqceBrrvjodaZR hCacAt6nJM0RFgptFYFybPOCSiiDdaKmlS5YiZWwmjk9syhhvI93lQVcckXnzUsA88Yg WBzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k125-v6si955859pgk.315.2018.07.26.03.12.41; Thu, 26 Jul 2018 03:12:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729254AbeGZL2C (ORCPT + 99 others); Thu, 26 Jul 2018 07:28:02 -0400 Received: from mga18.intel.com ([134.134.136.126]:19962 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729053AbeGZL2C (ORCPT ); Thu, 26 Jul 2018 07:28:02 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 03:11:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,404,1526367600"; d="scan'208";a="67674979" Received: from unknown (HELO [10.239.13.97]) ([10.239.13.97]) by FMSMGA003.fm.intel.com with ESMTP; 26 Jul 2018 03:11:41 -0700 Message-ID: <5B599F5F.2070705@intel.com> Date: Thu, 26 Jul 2018 18:15:59 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yury Norov CC: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, corbet@lwn.net, linux@rasmusvillemoes.dk, dgilbert@redhat.com, Andy Shevchenko Subject: Re: [PATCH] linux/bitmap.h: fix BITMAP_LAST_WORD_MASK References: <1532592471-21177-1-git-send-email-wei.w.wang@intel.com> <20180726093728.GA9069@yury-thinkpad> In-Reply-To: <20180726093728.GA9069@yury-thinkpad> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/26/2018 05:37 PM, Yury Norov wrote: > On Thu, Jul 26, 2018 at 04:07:51PM +0800, Wei Wang wrote: >> The existing BITMAP_LAST_WORD_MASK macro returns 0xffffffff if nbits is >> 0. This patch changes the macro to return 0 when there is no bit needs to >> be masked. > I think this is intentional behavour. Previous version did return ~0UL > explicitly in this case. See patch 89c1e79eb3023 (linux/bitmap.h: improve > BITMAP_{LAST,FIRST}_WORD_MASK) from Rasmus. Yes, I saw that. But it seems confusing for the corner case that nbits=0 (no bits to mask), the macro returns with all the bits set. > > Introducing conditional branch would affect performance. All existing > code checks nbits for 0 before handling last word where needed > explicitly. So I think we'd better change nothing here. I think that didn't save the conditional branch essentially, because it's just moved from inside this macro to the caller as you mentioned. If callers missed the check for some reason and passed 0 to the macro, they will get something unexpected. Current callers like __bitmap_weight, __bitmap_equal, and others, they have if (bits % BITS_PER_LONG) w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits)); we could remove the "if" check by "w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits % BITS_PER_LONG));" the branch is the same. Best, Wei