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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 801CBC433FE for ; Thu, 2 Dec 2021 00:31:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354569AbhLBAfO (ORCPT ); Wed, 1 Dec 2021 19:35:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354555AbhLBAfF (ORCPT ); Wed, 1 Dec 2021 19:35:05 -0500 Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95CCCC061748; Wed, 1 Dec 2021 16:31:43 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id g9so21510077qvd.2; Wed, 01 Dec 2021 16:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=UYmHlVbMSQbQAn62a50WlYWlw5WYikEw/HKO8MU8o20=; b=d9ufFBZIjBeCnfJhxkhOJHR4U6gA3sYY5/+OartHrmtyqhNuwpEH+tfc93YA7tEDao yOKDodcNFRle3eMMLCg2FH/Tcgr7cW593yntXLl1utZLUJtVShRNQEOc9NvEo4hEL1rm L2l6bxTExKPSRmbnMRKqIcZhoOpd63W1ZKagDrFCRbYIcYvSgN+CxBxrwTxGRSsHeVKf UXZK5TS9EbCKBOwmJzZ51FgzKmkah4fU/bnP1hNtNTskTK6qjluwzPEk7uWUTAkKCdZ1 XxzA5TtEBQPg9PU9R4bStLW9Ne4zdJoIM+RpRwYI7AmQcqEYlTEIoOnEsCuvtTzXmNFj 00eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=UYmHlVbMSQbQAn62a50WlYWlw5WYikEw/HKO8MU8o20=; b=DqgKolkPKqrXWQ9HL31Gh9PdPZs17c/UeEKZhGq60VRHXQ6uTNba6E/gNEUxut08dv BHOQn9E98Ihcvm1zXUgxhpbpnnEjF0jlav6odkYf/Joq6Rr7OvVz5ikG1n3dScMllSfV bbib4a7agBzI+XqmGmgPWRjrmrEbqzKgWOQs9W9OXoh95Jeb73VIC5Ybs0Cf8BEJN7zO dw6xVat2T54fpTuZzynPwMSsduLVyroCpi+LqLusdQDuUXsk3/Lfup4/2g+Aik850tNm vsC1vU3KSAOFl9M0aptStnfAVXSUAL9aj52YcX/gpW68+Od52EgD/S5I7nmCouZhGygC KWlA== X-Gm-Message-State: AOAM531xs/j1H7toXiM+CsSCkZxtlJtD5205OnDQr9ckExVG1T5rtFcu djcGDJZSzKqo5WWxMOuislJkR1zSj3cXaQ== X-Google-Smtp-Source: ABdhPJwpuPpSi7n83vlL+jLX5fyPRTIJyAHbiKfUe+xvjm76YV/xzPPNg/iMW1GhI6PSi3iKc0YBEA== X-Received: by 2002:a05:6214:ccc:: with SMTP id 12mr9930154qvx.8.1638405102640; Wed, 01 Dec 2021 16:31:42 -0800 (PST) Received: from localhost ([66.216.211.25]) by smtp.gmail.com with ESMTPSA id l1sm690890qkp.125.2021.12.01.16.31.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Dec 2021 16:31:42 -0800 (PST) Date: Wed, 1 Dec 2021 16:31:40 -0800 From: Yury Norov To: =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Cc: linux-kernel@vger.kernel.org, "James E.J. Bottomley" , "Paul E. McKenney" , "Martin K. Petersen" , "Rafael J. Wysocki" , Russell King , Amitkumar Karwar , Alexey Klimov , linux-alpha@vger.kernel.org, Alexander Shishkin , Andy Gross , Mike Marciniszyn , Petr Mladek , Andrew Morton , Andrew Lunn , Andi Kleen , Tejun Heo , Ard Biesheuvel , Vlastimil Babka , Anup Patel , linux-ia64@vger.kernel.org, Andy Shevchenko , Andy Lutomirski , Matti Vaittinen , Mel Gorman , Christoph Hellwig , Palmer Dabbelt , Catalin Marinas , Rasmus Villemoes , Borislav Petkov , Arnd Bergmann , Arnaldo Carvalho de Melo , Stephen Rothwell , David Laight , Sunil Goutham , David Airlie , Thomas Gleixner , Dave Hansen , Viresh Kumar , Daniel Vetter , bcm-kernel-feedback-list@broadcom.com, Christoph Lameter , linux-crypto@vger.kernel.org, Hans de Goede , linux-mm@kvack.org, Guo Ren , linux-snps-arc@lists.infradead.org, Geetha sowjanya , Mark Rutland , Dinh Nguyen , Mauro Carvalho Chehab , Dennis Zhou , Michael Ellerman , Heiko Carstens , Nicholas Piggin , Greg Kroah-Hartman , Peter Zijlstra , Geert Uytterhoeven , Randy Dunlap , Roy Pledge , Saeed Mahameed , Jens Axboe , Jason Wessel , Jakub Kicinski , Sergey Senozhatsky , Ingo Molnar , Stephen Boyd , Ian Rogers , Steven Rostedt , Sagi Grimberg , Sudeep Holla , Kalle Valo , Tariq Toukan , Juri Lelli , Thomas Bogendoerfer , Jonathan Cameron , Ulf Hansson , Jiri Olsa , Vineet Gupta , Solomon Peachy , Vivien Didelot , Lee Jones , Will Deacon , Krzysztof Kozlowski , kvm@vger.kernel.org, Kees Cook , linux-arm-kernel@lists.infradead.org, Subbaraya Sundeep , linux-csky@vger.kernel.org, Marcin Wojtas , linux-mips@vger.kernel.org, Marc Zyngier , linux-perf-users@vger.kernel.org, Vincent Guittot , linux-s390@vger.kernel.org, Mark Gross , linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/9] lib/bitmap: optimize bitmap_weight() usage Message-ID: <20211202003140.GA430494@lapt> References: <20211128035704.270739-1-yury.norov@gmail.com> <20211129063839.GA338729@lapt> <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Nov 29, 2021 at 04:34:07PM +0000, Michał Mirosław wrote: > Dnia 29 listopada 2021 06:38:39 UTC, Yury Norov napisał/a: > >On Sun, Nov 28, 2021 at 07:03:41PM +0100, mirq-test@rere.qmqm.pl wrote: > >> On Sat, Nov 27, 2021 at 07:56:55PM -0800, Yury Norov wrote: > >> > In many cases people use bitmap_weight()-based functions like this: > >> > > >> > if (num_present_cpus() > 1) > >> > do_something(); > >> > > >> > This may take considerable amount of time on many-cpus machines because > >> > num_present_cpus() will traverse every word of underlying cpumask > >> > unconditionally. > >> > > >> > We can significantly improve on it for many real cases if stop traversing > >> > the mask as soon as we count present cpus to any number greater than 1: > >> > > >> > if (num_present_cpus_gt(1)) > >> > do_something(); > >> > > >> > To implement this idea, the series adds bitmap_weight_{eq,gt,le} > >> > functions together with corresponding wrappers in cpumask and nodemask. > >> > >> Having slept on it I have more structured thoughts: > >> > >> First, I like substituting bitmap_empty/full where possible - I think > >> the change stands on its own, so could be split and sent as is. > > > >Ok, I can do it. > > > >> I don't like the proposed API very much. One problem is that it hides > >> the comparison operator and makes call sites less readable: > >> > >> bitmap_weight(...) > N > >> > >> becomes: > >> > >> bitmap_weight_gt(..., N) > >> > >> and: > >> bitmap_weight(...) <= N > >> > >> becomes: > >> > >> bitmap_weight_lt(..., N+1) > >> or: > >> !bitmap_weight_gt(..., N) > >> > >> I'd rather see something resembling memcmp() API that's known enough > >> to be easier to grasp. For above examples: > >> > >> bitmap_weight_cmp(..., N) > 0 > >> bitmap_weight_cmp(..., N) <= 0 > >> ... > > > >bitmap_weight_cmp() cannot be efficient. Consider this example: > > > >bitmap_weight_lt(1000 0000 0000 0000, 1) == false > > ^ > > stop here > > > >bitmap_weight_cmp(1000 0000 0000 0000, 1) == 0 > > ^ > > stop here > > > >I agree that '_gt' is less verbose than '>', but the advantage of > >'_gt' over '>' is proportional to length of bitmap, and it means > >that this API should exist. > > Thank you for the example. Indeed, for less-than to be efficient here you would need to replace > bitmap_weight_cmp(..., N) < 0 > with > bitmap_weight_cmp(..., N-1) <= 0 Indeed, thanks for pointing to it. > It would still be more readable, I think. To be honest, I'm not sure that bitmap_weight_cmp(..., N-1) <= 0 would be an obvious replacement for the original bitmap_weight(...) < N comparing to bitmap_weight_lt(..., N) I think the best thing I can do is to add bitmap_weight_cmp() as you suggested, and turn lt and others to be wrappers on it. This will let people choose a better function in each case. I also think that for v2 it would be better to drop the conversion for short bitmaps, except for switching to bitmap_empty(), because in that case readability wins over performance; if no objections. Thanks, Yury