Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp674307rdb; Fri, 6 Oct 2023 15:36:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFH3tAtln+ZfBWHwn1zClXsk0MZk3cmmf4YeXov5owN7aRQl1fFTI+z2PCbPNT0jXY75QsR X-Received: by 2002:a05:6871:451:b0:1dc:ddcd:876f with SMTP id e17-20020a056871045100b001dcddcd876fmr10497302oag.41.1696631775097; Fri, 06 Oct 2023 15:36:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696631775; cv=none; d=google.com; s=arc-20160816; b=EDAlxwd9wodu3bByBCX2Di+WGXw6J9OY+PLAkjVr6qPaLKs52tcH8+QZuDuKObCe8b q45Ivg+wfWlL+bnDQFqcrzNkeV71i7O6NAzlbYtSMINlx+3Nl2WYgZ8kfMVPvFYho3Dx J9WQOvrDF1rS93m/EWgVrRcCYNsoGyDdw70zqlU1AJGFA6tvMEcbV/UzHqeXWpRCIXj8 mPhZh9vFn+RQtyQz6UTerwy+63Ikt+CsIv8voQ5WOuTqYppxVK0dCsIld6SoG0jHkVb8 DFXEbnIj9qBkMqm34STYLxL6Fq0/wwOwn+NjpIH0aLI3Nb8vM0nHy+63vmgR6rXO/Zjo 53KA== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=llH4t7J63AaEPzQkwWh0fjeekIthRYPqlI68ZdJOsjQ=; fh=rWwnF/Ui56aEfmnkP49SCg/ID4wBDddUmsGC2YB2AcM=; b=cgwy3hYLPIuzq7RPmfSq11kbw1TWCz2Aj769TsQgI9l7+ekbuodRw0PGNAodjK6wbl Pv4EtEkz1AUYUf+m6xh6CmFABhElhMAGXQfrnFurSFu5hYFk6L+e4nnAp8OcDtCwz3v5 yD0gHtXYVtDKsCDVaUwuPgPCxhcDFqtWTypAMGwKPSi0KZA+i/dsmioWZBhLmED3mhW6 lDEouuXLO6Jli0d8i4YuOHaMKPnxIE/eKIgS8zU1BjpAfcVA3jGzU/JRCbb0GTTMH7tl F3Z5ssoSSBVj3wq7Sa5LT/cCcV1B//9p8P+62wZe/QA7wuGzXqIU4s4xhpGT7ZsuGDOm ygog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FldwVKeQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id cn11-20020a056a00340b00b0068c01fba736si2385678pfb.301.2023.10.06.15.36.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 15:36:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FldwVKeQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id C9A1F8365242; Fri, 6 Oct 2023 15:36:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233726AbjJFWfy (ORCPT + 99 others); Fri, 6 Oct 2023 18:35:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233700AbjJFWfx (ORCPT ); Fri, 6 Oct 2023 18:35:53 -0400 Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 648209F for ; Fri, 6 Oct 2023 15:35:52 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id ada2fe7eead31-452863742f3so1238786137.1 for ; Fri, 06 Oct 2023 15:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696631751; x=1697236551; 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=llH4t7J63AaEPzQkwWh0fjeekIthRYPqlI68ZdJOsjQ=; b=FldwVKeQPxekC/50VmwGYtbKu6FRrOPTH0h8+zWFcIyPS5PwFH2wXeiFPjjbdqAYZS bibi9G0bD2xbqOcQwYXAPX8khN1m0jY/sq16H1wIW8Fhyqodo/ERI8yKXZKU9LY1tLpJ D54ZBRpJHFCvfFMaAdGjda9qV4r2eMLdHUVmg+Kq97lGUxDniAXVtdeL/euWDddpJKx2 a82ad/keEptpQonx5VxhVv/d+PXW82G1ThkWCVRWwtLpy8ZM8wYhCH2M3KfW5cGjSLOv HXr8ypw+LosXW3tj00FzE76Tx2aJo3Y7knUvzTsFCYXMwC5yTLmKEJ0d5c2sl8Q8Mz2K l+Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696631751; x=1697236551; 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=llH4t7J63AaEPzQkwWh0fjeekIthRYPqlI68ZdJOsjQ=; b=Zd3FzlWlyhMEW5IZcxxAv7fAfb379k1GDncQRjuCvoSFsuhUvWtv4K/medkSSVUa4S IeXdo0qIFWhekOPK6i8blALz+huPVP3ZMTE980P0c2T/0jVPB/b2x8n76mTtxFev6vhj KT8oXKti/EdWk0Ub7F/7UKjWter2P9P8rhW/QG8t/hq8YnhFckIkrSZrYCmV0HIT4pWq j6ABRkdCAiv40LSNYQ1Q9ymcLGWOdHpF+Twmk8AM1pqWtbAdKXmI9ev1BWU/9aUK9M9K znsCkJe1hPJSvvtqPot/LW0vwyW2Tj0rya80QiUgMvg7uxOXdb7EMr9Zo1WIf6pApono fHgw== X-Gm-Message-State: AOJu0Yxx3hqubB/0vLrtbBbbBFPyjm+IRCSpsdA5Py5cmva+r8Ay+9HF n7v83ZWYKtViUdB8BPEig5QyBIGNK3HOFQ== X-Received: by 2002:a67:de97:0:b0:44e:e7d7:6847 with SMTP id r23-20020a67de97000000b0044ee7d76847mr9518443vsk.7.1696631751349; Fri, 06 Oct 2023 15:35:51 -0700 (PDT) Received: from localhost ([2607:fb90:be24:c307:bb4d:85d4:4340:a030]) by smtp.gmail.com with ESMTPSA id n3-20020a67e043000000b004527ba543c6sm1084717vsl.1.2023.10.06.15.35.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 15:35:50 -0700 (PDT) Date: Fri, 6 Oct 2023 15:35:49 -0700 From: Yury Norov To: Alexander Potapenko Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.com, andriy.shevchenko@linux.intel.com, aleksander.lobakin@intel.com, linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eugenis@google.com, syednwaris@gmail.com, william.gray@linaro.org, Arnd Bergmann Subject: Re: [PATCH v6 1/5] lib/bitmap: add bitmap_{read,write}() Message-ID: References: <20231006134529.2816540-1-glider@google.com> <20231006134529.2816540-2-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231006134529.2816540-2-glider@google.com> X-Spam-Status: No, score=3.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 06 Oct 2023 15:36:08 -0700 (PDT) X-Spam-Level: ** On Fri, Oct 06, 2023 at 03:45:25PM +0200, Alexander Potapenko wrote: > From: Syed Nayyar Waris > > The two new functions allow reading/writing values of length up to > BITS_PER_LONG bits at arbitrary position in the bitmap. > > The code was taken from "bitops: Introduce the for_each_set_clump macro" > by Syed Nayyar Waris with a number of changes and simplifications: > - instead of using roundup(), which adds an unnecessary dependency > on , we calculate space as BITS_PER_LONG-offset; > - indentation is reduced by not using else-clauses (suggested by > checkpatch for bitmap_get_value()); > - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read() > and bitmap_write(); > - some redundant computations are omitted. > > Cc: Arnd Bergmann > Signed-off-by: Syed Nayyar Waris > Signed-off-by: William Breathitt Gray > Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris@gmail.com/ > Suggested-by: Yury Norov > Co-developed-by: Alexander Potapenko > Signed-off-by: Alexander Potapenko > > --- > This patch was previously called "lib/bitmap: add > bitmap_{set,get}_value()" > (https://lore.kernel.org/lkml/20230720173956.3674987-2-glider@google.com/) > > v6: > - As suggested by Yury Norov, do not require bitmap_read(..., 0) to > return 0. > > v5: > - Address comments by Yury Norov: > - updated code comments and patch title/description > - replace GENMASK(nbits - 1, 0) with BITMAP_LAST_WORD_MASK(nbits) > - more compact bitmap_write() implementation > > v4: > - Address comments by Andy Shevchenko and Yury Norov: > - prevent passing values >= 64 to GENMASK() > - fix commit authorship > - change comments > - check for unlikely(nbits==0) > - drop unnecessary const declarations > - fix kernel-doc comments > - rename bitmap_{get,set}_value() to bitmap_{read,write}() > --- > include/linux/bitmap.h | 68 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 68 insertions(+) > > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h > index 03644237e1efb..e72c054d21d48 100644 > --- a/include/linux/bitmap.h > +++ b/include/linux/bitmap.h > @@ -76,7 +76,11 @@ struct device; > * bitmap_to_arr32(buf, src, nbits) Copy nbits from buf to u32[] dst > * bitmap_to_arr64(buf, src, nbits) Copy nbits from buf to u64[] dst > * bitmap_get_value8(map, start) Get 8bit value from map at start > + * bitmap_read(map, start, nbits) Read an nbits-sized value from > + * map at start > * bitmap_set_value8(map, value, start) Set 8bit value to map at start > + * bitmap_write(map, value, start, nbits) Write an nbits-sized value to > + * map at start > * > * Note, bitmap_zero() and bitmap_fill() operate over the region of > * unsigned longs, that is, bits behind bitmap till the unsigned long > @@ -583,6 +587,33 @@ static inline unsigned long bitmap_get_value8(const unsigned long *map, > return (map[index] >> offset) & 0xFF; > } > > +/** > + * bitmap_read - read a value of n-bits from the memory region > + * @map: address to the bitmap memory region > + * @start: bit offset of the n-bit value > + * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG > + * > + * Returns: value of nbits located at the @start bit offset within the @map > + * memory region. > + */ > +static inline unsigned long bitmap_read(const unsigned long *map, > + unsigned long start, > + unsigned long nbits) > +{ > + size_t index = BIT_WORD(start); > + unsigned long offset = start % BITS_PER_LONG; > + unsigned long space = BITS_PER_LONG - offset; > + unsigned long value_low, value_high; > + > + if (unlikely(!nbits)) > + return 0; > + if (space >= nbits) > + return (map[index] >> offset) & GENMASK(nbits - 1, 0); > + value_low = map[index] & BITMAP_FIRST_WORD_MASK(start); > + value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits); > + return (value_low >> offset) | (value_high << space); > +} > + > /** > * bitmap_set_value8 - set an 8-bit value within a memory region > * @map: address to the bitmap memory region > @@ -599,6 +630,43 @@ static inline void bitmap_set_value8(unsigned long *map, unsigned long value, > map[index] |= value << offset; > } > > +/** > + * bitmap_write - write n-bit value within a memory region > + * @map: address to the bitmap memory region > + * @value: value to write, clamped to nbits > + * @start: bit offset of the n-bit value > + * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG. > + * > + * bitmap_write() behaves similarly to @nbits calls of assign_bit(), i.e. bits > + * beyond @nbits are ignored: > + * > + * for (bit = 0; bit < nbits; bit++) > + * assign_bit(start + bit, bitmap, val & BIT(bit)); __assign_bit() > + */ 'behaves similarly' sounds like an understatement. I think, it behaves much faster because it can assign up to 64 bits at once, not mentioning the pressure on cache lines traffic. How faster - that's a good question. I'd be really pleased if you add a performance test for bitmap_write/read. Or I can do it myself later. You can find examples in the same lib/test_bitmap.c. > +static inline void bitmap_write(unsigned long *map, > + unsigned long value, > + unsigned long start, unsigned long nbits) > +{ > + size_t index = BIT_WORD(start); > + unsigned long offset = start % BITS_PER_LONG; > + unsigned long space = BITS_PER_LONG - offset; > + unsigned long mask; > + > + if (unlikely(!nbits)) > + return; can you please add more empty lines to separate blocks visually? > + mask = BITMAP_LAST_WORD_MASK(nbits); > + value &= mask; > + if (space >= nbits) { > + map[index] &= ~(mask << offset); > + map[index] |= value << offset; > + return; > + } > + map[index] &= ~BITMAP_FIRST_WORD_MASK(start); > + map[index] |= value << offset; > + map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits); > + map[index + 1] |= (value >> space); > +} I compiled the below fix on spark64 BE machine: --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -608,7 +608,7 @@ static inline unsigned long bitmap_read(const unsigned long *map, if (unlikely(!nbits)) return 0; if (space >= nbits) - return (map[index] >> offset) & GENMASK(nbits - 1, 0); + return (map[index] >> offset) & BITMAP_LAST_WORD_MASK(nbits); value_low = map[index] & BITMAP_FIRST_WORD_MASK(start); value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits); return (value_low >> offset) | (value_high << space); @@ -661,9 +661,9 @@ static inline void bitmap_write(unsigned long *map, map[index] |= value << offset; return; } - map[index] &= ~BITMAP_FIRST_WORD_MASK(start); + map[index] &= BITMAP_LAST_WORD_MASK(start); map[index] |= value << offset; - map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits); + map[index + 1] &= BITMAP_FIRST_WORD_MASK(start + nbits); map[index + 1] |= (value >> space); } All the tests are passed just as before, and there's no any difference reported by bloat-o-meter. Can you please use non-negation versions as they are more straightforward? > + > #endif /* __ASSEMBLY__ */ > > #endif /* __LINUX_BITMAP_H */ > -- > 2.42.0.609.gbb76f46606-goog