Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp664278ybz; Fri, 24 Apr 2020 07:15:21 -0700 (PDT) X-Google-Smtp-Source: APiQypIOUOlMyWsRXmKQLj7JhiM/kBZvu/5MLxVeDNBBpx90xjFtaRqB+TKNLzT/ctzlbYIf1jnV X-Received: by 2002:a17:906:e5a:: with SMTP id q26mr6888069eji.261.1587737721070; Fri, 24 Apr 2020 07:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587737721; cv=none; d=google.com; s=arc-20160816; b=XJHlXKpsVct0IvyewS5DZri/gkxbb20ApihNfp7NwE3ofOYPmgVh9H+16qbgF769xa gidqW7XrRd9wEsiljs3nybwxUIYMOpP83+lpu02xoNp483XOjOwS7dOo/Rc2RpurGC7P CrfZhpD3gpc7aMOXBidJzGVLtNpfOn/CQF3ZOK0oTqtg67oSZ5l3bjHiiIxCp9by1nXY wfQP1rL7gAcV48g9AnMA7Jke+DAJg1pt5p++rSPgaWoAGz3SrCnVBijB8EBleiv0Vk2q uc1aJwWXa784pEmteDheTozm9c3E5FLb1rEFtsLW1r0OXWnJ6h5bfxM7TQiB9VPW81vD v97Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2auNFQ9A6dH6IYlaTZ+8Pha6lYsLhM+hy6woXfXEnyg=; b=Eonzz3TA28zunwGD+OL1h/AdpinM+HsJUVqTrgbUrQM/fj5KV79C0tcmaqIp1TYTl2 fk6eDXA09+KOBoZHs53J/1WK4cv9KATdlKmMqEBa0DaihWrWfALojG5MXmn+mVkUGhDB 2rE2FVK1p3vMsjiQersH1nIY525NityNhnv1dtYiohpZVPbrMQuJM1bIgstLo8Y51RbM M2518hSeNjGRu5T331LN5tjyhFCcFBW9K1Cb1gXWZr+6d/NltLfh3VWo2vMUXx8tQxqm SUuZNnJr+nlIHFOkTX4OnJ09lxg+bZLn5VTY2fuBnYh795/FfNKgkNwDjgxkDGHOFlUr 2Ftw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g12si3275021ejw.314.2020.04.24.07.14.50; Fri, 24 Apr 2020 07:15:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728007AbgDXOKl (ORCPT + 99 others); Fri, 24 Apr 2020 10:10:41 -0400 Received: from bmailout1.hostsharing.net ([83.223.95.100]:57869 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727920AbgDXOKk (ORCPT ); Fri, 24 Apr 2020 10:10:40 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id B8F5A3000467A; Fri, 24 Apr 2020 16:10:37 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 9335B70E94E; Fri, 24 Apr 2020 16:10:37 +0200 (CEST) Date: Fri, 24 Apr 2020 16:10:37 +0200 From: Lukas Wunner To: Syed Nayyar Waris Cc: akpm@linux-foundation.org, andriy.shevchenko@linux.intel.com, vilhelm.gray@gmail.com, arnd@arndb.de, linus.walleij@linaro.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] bitops: Introduce the the for_each_set_clump macro Message-ID: <20200424141037.ersebbfe7xls37be@wunner.de> References: <20200424122521.GA5552@syed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200424122521.GA5552@syed> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 24, 2020 at 05:55:21PM +0530, Syed Nayyar Waris wrote: > +static inline void bitmap_set_value(unsigned long *map, > + unsigned long value, > + unsigned long start, unsigned long nbits) > +{ > + const size_t index = BIT_WORD(start); > + const unsigned long offset = start % BITS_PER_LONG; > + const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG); > + const unsigned long space = ceiling - start; > + > + value &= GENMASK(nbits - 1, 0); > + > + if (space >= nbits) { > + map[index] &= ~(GENMASK(nbits + offset - 1, offset)); > + map[index] |= value << offset; > + } else { > + 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); > + } > +} Sorry but what's the advantage of using this complicated function as a replacement for the much simpler bitmap_set_value8()? The drivers calling bitmap_set_value8() *know* that 8-bit accesses are possible and take advantage of that knowledge by using a small, speed-optimized function. Replacing that with a more complicated (potentially less performant) function doesn't seem to be a step forward. Thanks, Lukas