Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp812831ybe; Fri, 13 Sep 2019 06:46:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqzu9O2z2ssEfVnT8OMbdoIjOUW6iJYk/6QL6lN+IAQSUTZ4swKVKCvDFsXxoDPhIKXYGX8s X-Received: by 2002:a05:6402:286:: with SMTP id l6mr47847436edv.111.1568382404037; Fri, 13 Sep 2019 06:46:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568382404; cv=none; d=google.com; s=arc-20160816; b=xbWZtLZwKzuh7DUiIzVWTmzfXhj4neHuAdSX2SaifhsSbOqx378y0c1FqIyhtXtycG yf3NPFf5gb3/1umNFngLbO0FTxDV6NiGq5sOPxvlaIsNufYo4E0+bg2rBjP0hi5KrHeJ 3hfVFP65E8vPHc0GZvbSP1i4yweGkJk2ZPQLHNHeA66iUONdEoNCtZMuxsNUFy0fnS/F x6ZXE2GgnzVNEr3nwXdsSF6OkEPbmxCioBWUCvmXceDLH1BXTm9SSHer29Pb0PqMlkVF aCau9bSImj3KjKoIdNgnhQoFsttXfLtl2czZymhxPm8Sn0fJcKmdF94w3N2QcwY9VuoQ kBnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:organization:subject:cc:to:from:date :content-transfer-encoding:mime-version; bh=OFq7cL3Tc8TEkaxfT8jaJhav0HsrNc/G5vZQE+bgLls=; b=QRkPa/oGxnwmqxDFm/pSNLXXhqbo32YI3xciZhHnEpHAIsyH4SrLh3cg6zjxI/L8WW kexwxrrJh67zSJfp7ASOKz2JykQRZMSuwRazYOGC8O6jBxTqgZLPf2dFjjV4POZbB7SN aetoeTnL5kGsyBfOK87UcHja8Z446naGBuyZS4FNzfgzuuBMgJnERd8sQqAwhOSUcxRx 68jUgDoocQhnmKp1/5DXrMPq5LAwv247wu/YzgP1L2BnayKAQqTMIsLXEYI5s0CiMCtT ooOgyaVSkVdMRmb1X8jyJjs7tDNO2ognhfudTXDhRq9UtiDBQfJWVJOGxPvK3uWjl4nT 7Mlw== 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=ispras.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ba7si11933892edb.76.2019.09.13.06.46.18; Fri, 13 Sep 2019 06:46:44 -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=ispras.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390075AbfIMNl1 (ORCPT + 99 others); Fri, 13 Sep 2019 09:41:27 -0400 Received: from mail.ispras.ru ([83.149.199.45]:32892 "EHLO mail.ispras.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388927AbfIMNl1 (ORCPT ); Fri, 13 Sep 2019 09:41:27 -0400 Received: from mail.ispras.ru (localhost [127.0.0.1]) by mail.ispras.ru (Postfix) with ESMTPSA id 9EB1654008B; Fri, 13 Sep 2019 16:41:24 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 13 Sep 2019 16:41:24 +0300 From: efremov To: Denis Efremov Cc: Matthew Wilcox , akpm@linux-foundation.org, Akinobu Mita , Jan Kara , linux-kernel@vger.kernel.org, Matthew Wilcox , dm-devel@redhat.com, linux-fsdevel@vger.kernel.org, linux-media@vger.kernel.org, Erdem Tumurov , Vladimir Shelekhov Subject: Re: [PATCH v2] lib/memweight.c: open codes bitmap_weight() Organization: ISPRAS In-Reply-To: <85d9e45a-9631-a139-2d65-86a6753a35e6@ispras.ru> References: <20190821074200.2203-1-efremov@ispras.ru> <20190824100102.1167-1-efremov@ispras.ru> <20190825061158.GC28002@bombadil.infradead.org> <20190826183956.GF15933@bombadil.infradead.org> <85d9e45a-9631-a139-2d65-86a6753a35e6@ispras.ru> Message-ID: X-Sender: efremov@ispras.ru User-Agent: Roundcube Webmail/1.1.2 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry, no question, pointer alignment of course. Denis Efremov писал 2019-09-13 14:48: > Hi, > > Sorry for reviving this conversation, but it looks to me like > this function could be reduced to a single bitmap_weight call: > > static inline size_t memweight(const void *ptr, size_t bytes) > { > BUG_ON(bytes >= UINT_MAX / BITS_PER_BYTE); > return bitmap_weight(ptr, bytes * BITS_PER_BYTE); > } > > Comparing to the current implementation > https://elixir.bootlin.com/linux/latest/source/lib/memweight.c#L11 > this results in a signification simplification. > > __bitmap_weight already count last bits with hweight_long as we > discussed earlier. > > int __bitmap_weight(const unsigned long *bitmap, unsigned int bits) > { > ... > if (bits % BITS_PER_LONG) > w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits)); > ... > } > > and __arch_hweight* functions use popcnt instruction. > > I've briefly tested the equivalence of 2 implementations on x86_64 with > fuzzing here: > https://gist.github.com/evdenis/95a8b9b8041e09368b31c3a9510491a5 > > What do you think making this function static inline and moving it > to include/linux/string.h? I could prepare a patch for it and add some > tests for > memweight and bitmap_weight. Or maybe I miss something again? > > Best regards, > Denis