From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Subject: Re: [PATCH 0/9] lib/bitmap: optimize bitmap_weight() usage Date: Wed, 1 Dec 2021 16:31:40 -0800 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-Transfer-Encoding: 8bit Return-path: 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== Content-Disposition: inline In-Reply-To: <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> List-ID: Content-Type: text/plain; charset="utf-8" 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 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 A7FD9C4332F for ; Thu, 2 Dec 2021 00:31:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354568AbhLBAfQ (ORCPT ); Wed, 1 Dec 2021 19:35:16 -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-csky@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Date: Thu, 02 Dec 2021 00:31:40 +0000 Subject: Re: [PATCH 0/9] lib/bitmap: optimize bitmap_weight() usage Message-Id: <20211202003140.GA430494@lapt> List-Id: References: <20211128035704.270739-1-yury.norov@gmail.com> <20211129063839.GA338729@lapt> <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> In-Reply-To: <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C7347C433F5 for ; Thu, 2 Dec 2021 00:32:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=V9o5ifyskDsq7wQIMzCJN4+v6Gg8aQWONJKaQ5Hiako=; b=2qDxYgiJnII4p2 r8nW9KeoJeOehkMaXr6zKdKKU1oXW+y3pDftPQmwUp2GcBch060OBQhdzvycizNqnQTsh+239WbxN 5CytkLcgxDlnL0MvsZK/1TiYUzarzG7wBDIBAhiNxKy51sdSEo3SOOR3KfmuZH/wVsMgR6dt0BFad eQe8RzXNovGaYgOR2B/AboQp4QjM0J2+QHSx2rGKlq+xlqLfaf9ILXc+6Za1YEaw67TdOsgdPTBcU YcrZ1AX+10s8bpO4+XxWUtHd6DEwzlHNuIKnnsW050bALCNBJ6roSjLsONm1LIfABQ4wApTp0EkzW C89V4D6GMSoKUtPF9iyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1msa0p-00ASJh-TE; Thu, 02 Dec 2021 00:31:47 +0000 Received: from mail-qv1-xf2d.google.com ([2607:f8b0:4864:20::f2d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1msa0m-00ASIo-JW; Thu, 02 Dec 2021 00:31:46 +0000 Received: by mail-qv1-xf2d.google.com with SMTP id u16so23421365qvk.4; 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=pd1ChqY40LJyrsgGgWQ1FhhbbhYRMG756kDQL09DNwl/xsyk36pl/y58qq58zYSo07 tcr5Cj58zWlwHlATAYtKQ8ElSFkMx/dDno+WGHBJ3nlgRKYlLJLFCn4U5MmI/jAJo7xm U0Uh+nH8V6z6RiM62KXlrtfHAtEluzhbfJzWLo6FO/ufezK8z3p0vcg3rfpjrjHw2SBw qJriepRTLx7glWOXCih/m+Mfivn3b/LuKOnKNn1q67PUKszcOO5S5x6e6cA/ephJK9o7 b/vAD4U36VMSaRDqycpYuK8OjOcxIE3M1O9VJ3i/p5SCRRIaeyjrz9p7V99TRtWbxpe9 /dKg== X-Gm-Message-State: AOAM533jSBnyQ3FMnVhZgwCzZgV79eQS5SdJx4AynqJ7hKlRVyFWUZJi cV3KGsUKR02MEvVcbH7lYhs= 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-Disposition: inline In-Reply-To: <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211201_163144_696773_B4EC5D85 X-CRM114-Status: GOOD ( 34.88 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gTW9uLCBOb3YgMjksIDIwMjEgYXQgMDQ6MzQ6MDdQTSArMDAwMCwgTWljaGHFgiBNaXJvc8WC YXcgd3JvdGU6Cj4gRG5pYSAyOSBsaXN0b3BhZGEgMjAyMSAwNjozODozOSBVVEMsIFl1cnkgTm9y b3YgPHl1cnkubm9yb3ZAZ21haWwuY29tPiBuYXBpc2HFgi9hOgo+ID5PbiBTdW4sIE5vdiAyOCwg MjAyMSBhdCAwNzowMzo0MVBNICswMTAwLCBtaXJxLXRlc3RAcmVyZS5xbXFtLnBsIHdyb3RlOgo+ ID4+IE9uIFNhdCwgTm92IDI3LCAyMDIxIGF0IDA3OjU2OjU1UE0gLTA4MDAsIFl1cnkgTm9yb3Yg d3JvdGU6Cj4gPj4gPiBJbiBtYW55IGNhc2VzIHBlb3BsZSB1c2UgYml0bWFwX3dlaWdodCgpLWJh c2VkIGZ1bmN0aW9ucyBsaWtlIHRoaXM6Cj4gPj4gPiAKPiA+PiA+IAlpZiAobnVtX3ByZXNlbnRf Y3B1cygpID4gMSkKPiA+PiA+IAkJZG9fc29tZXRoaW5nKCk7Cj4gPj4gPiAKPiA+PiA+IFRoaXMg bWF5IHRha2UgY29uc2lkZXJhYmxlIGFtb3VudCBvZiB0aW1lIG9uIG1hbnktY3B1cyBtYWNoaW5l cyBiZWNhdXNlCj4gPj4gPiBudW1fcHJlc2VudF9jcHVzKCkgd2lsbCB0cmF2ZXJzZSBldmVyeSB3 b3JkIG9mIHVuZGVybHlpbmcgY3B1bWFzawo+ID4+ID4gdW5jb25kaXRpb25hbGx5Lgo+ID4+ID4g Cj4gPj4gPiBXZSBjYW4gc2lnbmlmaWNhbnRseSBpbXByb3ZlIG9uIGl0IGZvciBtYW55IHJlYWwg Y2FzZXMgaWYgc3RvcCB0cmF2ZXJzaW5nCj4gPj4gPiB0aGUgbWFzayBhcyBzb29uIGFzIHdlIGNv dW50IHByZXNlbnQgY3B1cyB0byBhbnkgbnVtYmVyIGdyZWF0ZXIgdGhhbiAxOgo+ID4+ID4gCj4g Pj4gPiAJaWYgKG51bV9wcmVzZW50X2NwdXNfZ3QoMSkpCj4gPj4gPiAJCWRvX3NvbWV0aGluZygp Owo+ID4+ID4gCj4gPj4gPiBUbyBpbXBsZW1lbnQgdGhpcyBpZGVhLCB0aGUgc2VyaWVzIGFkZHMg Yml0bWFwX3dlaWdodF97ZXEsZ3QsbGV9Cj4gPj4gPiBmdW5jdGlvbnMgdG9nZXRoZXIgd2l0aCBj b3JyZXNwb25kaW5nIHdyYXBwZXJzIGluIGNwdW1hc2sgYW5kIG5vZGVtYXNrLgo+ID4+IAo+ID4+ IEhhdmluZyBzbGVwdCBvbiBpdCBJIGhhdmUgbW9yZSBzdHJ1Y3R1cmVkIHRob3VnaHRzOgo+ID4+ IAo+ID4+IEZpcnN0LCBJIGxpa2Ugc3Vic3RpdHV0aW5nIGJpdG1hcF9lbXB0eS9mdWxsIHdoZXJl IHBvc3NpYmxlIC0gSSB0aGluawo+ID4+IHRoZSBjaGFuZ2Ugc3RhbmRzIG9uIGl0cyBvd24sIHNv IGNvdWxkIGJlIHNwbGl0IGFuZCBzZW50IGFzIGlzLgo+ID4KPiA+T2ssIEkgY2FuIGRvIGl0Lgo+ ID4KPiA+PiBJIGRvbid0IGxpa2UgdGhlIHByb3Bvc2VkIEFQSSB2ZXJ5IG11Y2guIE9uZSBwcm9i bGVtIGlzIHRoYXQgaXQgaGlkZXMKPiA+PiB0aGUgY29tcGFyaXNvbiBvcGVyYXRvciBhbmQgbWFr ZXMgY2FsbCBzaXRlcyBsZXNzIHJlYWRhYmxlOgo+ID4+IAo+ID4+IAliaXRtYXBfd2VpZ2h0KC4u LikgPiBOCj4gPj4gCj4gPj4gYmVjb21lczoKPiA+PiAKPiA+PiAJYml0bWFwX3dlaWdodF9ndCgu Li4sIE4pCj4gPj4gCj4gPj4gYW5kOgo+ID4+IAliaXRtYXBfd2VpZ2h0KC4uLikgPD0gTgo+ID4+ IAo+ID4+IGJlY29tZXM6Cj4gPj4gCj4gPj4gCWJpdG1hcF93ZWlnaHRfbHQoLi4uLCBOKzEpCj4g Pj4gb3I6Cj4gPj4gCSFiaXRtYXBfd2VpZ2h0X2d0KC4uLiwgTikKPiA+PiAKPiA+PiBJJ2QgcmF0 aGVyIHNlZSBzb21ldGhpbmcgcmVzZW1ibGluZyBtZW1jbXAoKSBBUEkgdGhhdCdzIGtub3duIGVu b3VnaAo+ID4+IHRvIGJlIGVhc2llciB0byBncmFzcC4gRm9yIGFib3ZlIGV4YW1wbGVzOgo+ID4+ IAo+ID4+IAliaXRtYXBfd2VpZ2h0X2NtcCguLi4sIE4pID4gMAo+ID4+IAliaXRtYXBfd2VpZ2h0 X2NtcCguLi4sIE4pIDw9IDAKPiA+PiAJLi4uCj4gPgo+ID5iaXRtYXBfd2VpZ2h0X2NtcCgpIGNh bm5vdCBiZSBlZmZpY2llbnQuIENvbnNpZGVyIHRoaXMgZXhhbXBsZToKPiA+Cj4gPmJpdG1hcF93 ZWlnaHRfbHQoMTAwMCAwMDAwIDAwMDAgMDAwMCwgMSkgPT0gZmFsc2UKPiA+ICAgICAgICAgICAg ICAgICBeCj4gPiAgICAgICAgICAgICAgICAgc3RvcCBoZXJlCj4gPgo+ID5iaXRtYXBfd2VpZ2h0 X2NtcCgxMDAwIDAwMDAgMDAwMCAwMDAwLCAxKSA9PSAwCj4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIF4KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RvcCBo ZXJlCj4gPgo+ID5JIGFncmVlIHRoYXQgJ19ndCcgaXMgbGVzcyB2ZXJib3NlIHRoYW4gJz4nLCBi dXQgdGhlIGFkdmFudGFnZSBvZiAKPiA+J19ndCcgb3ZlciAnPicgaXMgcHJvcG9ydGlvbmFsIHRv IGxlbmd0aCBvZiBiaXRtYXAsIGFuZCBpdCBtZWFucwo+ID50aGF0IHRoaXMgQVBJIHNob3VsZCBl eGlzdC4KPiAKPiBUaGFuayB5b3UgZm9yIHRoZSBleGFtcGxlLiBJbmRlZWQsIGZvciBsZXNzLXRo YW4gdG8gYmUgZWZmaWNpZW50IGhlcmUgeW91IHdvdWxkIG5lZWQgdG8gcmVwbGFjZQo+ICBiaXRt YXBfd2VpZ2h0X2NtcCguLi4sIE4pIDwgMAo+IHdpdGgKPiAgYml0bWFwX3dlaWdodF9jbXAoLi4u LCBOLTEpIDw9IDAKCkluZGVlZCwgdGhhbmtzIGZvciBwb2ludGluZyB0byBpdC4KIAo+IEl0IHdv dWxkIHN0aWxsIGJlIG1vcmUgcmVhZGFibGUsIEkgdGhpbmsuCgpUbyBiZSBob25lc3QsIEknbSBu b3Qgc3VyZSB0aGF0CiAgICAgICAgYml0bWFwX3dlaWdodF9jbXAoLi4uLCBOLTEpIDw9IDAKd291 bGQgYmUgYW4gb2J2aW91cyByZXBsYWNlbWVudCBmb3IgdGhlIG9yaWdpbmFsCiAgICAgICAgYml0 bWFwX3dlaWdodCguLi4pIDwgTgpjb21wYXJpbmcgdG8gCiAgICAgICAgYml0bWFwX3dlaWdodF9s dCguLi4sIE4pCgpJIHRoaW5rIHRoZSBiZXN0IHRoaW5nIEkgY2FuIGRvIGlzIHRvIGFkZCBiaXRt YXBfd2VpZ2h0X2NtcCgpIGFzCnlvdSBzdWdnZXN0ZWQsIGFuZCB0dXJuIGx0IGFuZCBvdGhlcnMg dG8gYmUgd3JhcHBlcnMgb24gaXQuIFRoaXMKd2lsbCBsZXQgcGVvcGxlIGNob29zZSBhIGJldHRl ciBmdW5jdGlvbiBpbiBlYWNoIGNhc2UuCgpJIGFsc28gdGhpbmsgdGhhdCBmb3IgdjIgaXQgd291 bGQgYmUgYmV0dGVyIHRvIGRyb3AgdGhlIGNvbnZlcnNpb24KZm9yIHNob3J0IGJpdG1hcHMsIGV4 Y2VwdCBmb3Igc3dpdGNoaW5nIHRvIGJpdG1hcF9lbXB0eSgpLCBiZWNhdXNlCmluIHRoYXQgY2Fz ZSByZWFkYWJpbGl0eSB3aW5zIG92ZXIgcGVyZm9ybWFuY2U7IGlmIG5vIG9iamVjdGlvbnMuIAoK VGhhbmtzLApZdXJ5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpsaW51eC1yaXNjdiBtYWlsaW5nIGxpc3QKbGludXgtcmlzY3ZAbGlzdHMuaW5mcmFkZWFk Lm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJp c2N2Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C308BC433EF for ; Thu, 2 Dec 2021 00:31:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cbbui+yJ25W0pmzdF905SOsvbW4Nf0NyR/GIz9WLKL8=; b=iNdgi3U7obeM9B DqiTrQNVZNgTBFZC+pSb01LaWtkH69m/Ko058cte2nlyS1DoHlqnAG8gFyhNasCbpg2yuZBn009kn EBsOx0iHfjSHqmqfaLhGR+UGgvADDiX5NcAgcNqj6GcPj/quDT+QOLdrmJ9cTE/pwGVreT5cb9xP1 4AgsTLmJedGQ6tg1jEVuBaw6tT6ZHJ0h793nqXeXTNL0gdQCNZIBgji1G4yPBLLzPwem4M+wMtEM3 vtV0NYqpmldIadtSgMQofg0FX5z47xXTNwt8hC2OW69/wYcnlvCXINh7A9Ye2wSZ1Z6fK+zaV9UGO Tvj/riNr8gPvZek2j/1Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1msa0p-00ASJb-MF; Thu, 02 Dec 2021 00:31:47 +0000 Received: from mail-qv1-xf2d.google.com ([2607:f8b0:4864:20::f2d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1msa0m-00ASIo-JW; Thu, 02 Dec 2021 00:31:46 +0000 Received: by mail-qv1-xf2d.google.com with SMTP id u16so23421365qvk.4; 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=pd1ChqY40LJyrsgGgWQ1FhhbbhYRMG756kDQL09DNwl/xsyk36pl/y58qq58zYSo07 tcr5Cj58zWlwHlATAYtKQ8ElSFkMx/dDno+WGHBJ3nlgRKYlLJLFCn4U5MmI/jAJo7xm U0Uh+nH8V6z6RiM62KXlrtfHAtEluzhbfJzWLo6FO/ufezK8z3p0vcg3rfpjrjHw2SBw qJriepRTLx7glWOXCih/m+Mfivn3b/LuKOnKNn1q67PUKszcOO5S5x6e6cA/ephJK9o7 b/vAD4U36VMSaRDqycpYuK8OjOcxIE3M1O9VJ3i/p5SCRRIaeyjrz9p7V99TRtWbxpe9 /dKg== X-Gm-Message-State: AOAM533jSBnyQ3FMnVhZgwCzZgV79eQS5SdJx4AynqJ7hKlRVyFWUZJi cV3KGsUKR02MEvVcbH7lYhs= 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-Disposition: inline In-Reply-To: <3CD9ECD8-901E-497B-9AE1-0DDB02346892@rere.qmqm.pl> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211201_163144_696773_B4EC5D85 X-CRM114-Status: GOOD ( 34.88 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org T24gTW9uLCBOb3YgMjksIDIwMjEgYXQgMDQ6MzQ6MDdQTSArMDAwMCwgTWljaGHFgiBNaXJvc8WC YXcgd3JvdGU6Cj4gRG5pYSAyOSBsaXN0b3BhZGEgMjAyMSAwNjozODozOSBVVEMsIFl1cnkgTm9y b3YgPHl1cnkubm9yb3ZAZ21haWwuY29tPiBuYXBpc2HFgi9hOgo+ID5PbiBTdW4sIE5vdiAyOCwg MjAyMSBhdCAwNzowMzo0MVBNICswMTAwLCBtaXJxLXRlc3RAcmVyZS5xbXFtLnBsIHdyb3RlOgo+ ID4+IE9uIFNhdCwgTm92IDI3LCAyMDIxIGF0IDA3OjU2OjU1UE0gLTA4MDAsIFl1cnkgTm9yb3Yg d3JvdGU6Cj4gPj4gPiBJbiBtYW55IGNhc2VzIHBlb3BsZSB1c2UgYml0bWFwX3dlaWdodCgpLWJh c2VkIGZ1bmN0aW9ucyBsaWtlIHRoaXM6Cj4gPj4gPiAKPiA+PiA+IAlpZiAobnVtX3ByZXNlbnRf Y3B1cygpID4gMSkKPiA+PiA+IAkJZG9fc29tZXRoaW5nKCk7Cj4gPj4gPiAKPiA+PiA+IFRoaXMg bWF5IHRha2UgY29uc2lkZXJhYmxlIGFtb3VudCBvZiB0aW1lIG9uIG1hbnktY3B1cyBtYWNoaW5l cyBiZWNhdXNlCj4gPj4gPiBudW1fcHJlc2VudF9jcHVzKCkgd2lsbCB0cmF2ZXJzZSBldmVyeSB3 b3JkIG9mIHVuZGVybHlpbmcgY3B1bWFzawo+ID4+ID4gdW5jb25kaXRpb25hbGx5Lgo+ID4+ID4g Cj4gPj4gPiBXZSBjYW4gc2lnbmlmaWNhbnRseSBpbXByb3ZlIG9uIGl0IGZvciBtYW55IHJlYWwg Y2FzZXMgaWYgc3RvcCB0cmF2ZXJzaW5nCj4gPj4gPiB0aGUgbWFzayBhcyBzb29uIGFzIHdlIGNv dW50IHByZXNlbnQgY3B1cyB0byBhbnkgbnVtYmVyIGdyZWF0ZXIgdGhhbiAxOgo+ID4+ID4gCj4g Pj4gPiAJaWYgKG51bV9wcmVzZW50X2NwdXNfZ3QoMSkpCj4gPj4gPiAJCWRvX3NvbWV0aGluZygp Owo+ID4+ID4gCj4gPj4gPiBUbyBpbXBsZW1lbnQgdGhpcyBpZGVhLCB0aGUgc2VyaWVzIGFkZHMg Yml0bWFwX3dlaWdodF97ZXEsZ3QsbGV9Cj4gPj4gPiBmdW5jdGlvbnMgdG9nZXRoZXIgd2l0aCBj b3JyZXNwb25kaW5nIHdyYXBwZXJzIGluIGNwdW1hc2sgYW5kIG5vZGVtYXNrLgo+ID4+IAo+ID4+ IEhhdmluZyBzbGVwdCBvbiBpdCBJIGhhdmUgbW9yZSBzdHJ1Y3R1cmVkIHRob3VnaHRzOgo+ID4+ IAo+ID4+IEZpcnN0LCBJIGxpa2Ugc3Vic3RpdHV0aW5nIGJpdG1hcF9lbXB0eS9mdWxsIHdoZXJl IHBvc3NpYmxlIC0gSSB0aGluawo+ID4+IHRoZSBjaGFuZ2Ugc3RhbmRzIG9uIGl0cyBvd24sIHNv IGNvdWxkIGJlIHNwbGl0IGFuZCBzZW50IGFzIGlzLgo+ID4KPiA+T2ssIEkgY2FuIGRvIGl0Lgo+ ID4KPiA+PiBJIGRvbid0IGxpa2UgdGhlIHByb3Bvc2VkIEFQSSB2ZXJ5IG11Y2guIE9uZSBwcm9i bGVtIGlzIHRoYXQgaXQgaGlkZXMKPiA+PiB0aGUgY29tcGFyaXNvbiBvcGVyYXRvciBhbmQgbWFr ZXMgY2FsbCBzaXRlcyBsZXNzIHJlYWRhYmxlOgo+ID4+IAo+ID4+IAliaXRtYXBfd2VpZ2h0KC4u LikgPiBOCj4gPj4gCj4gPj4gYmVjb21lczoKPiA+PiAKPiA+PiAJYml0bWFwX3dlaWdodF9ndCgu Li4sIE4pCj4gPj4gCj4gPj4gYW5kOgo+ID4+IAliaXRtYXBfd2VpZ2h0KC4uLikgPD0gTgo+ID4+ IAo+ID4+IGJlY29tZXM6Cj4gPj4gCj4gPj4gCWJpdG1hcF93ZWlnaHRfbHQoLi4uLCBOKzEpCj4g Pj4gb3I6Cj4gPj4gCSFiaXRtYXBfd2VpZ2h0X2d0KC4uLiwgTikKPiA+PiAKPiA+PiBJJ2QgcmF0 aGVyIHNlZSBzb21ldGhpbmcgcmVzZW1ibGluZyBtZW1jbXAoKSBBUEkgdGhhdCdzIGtub3duIGVu b3VnaAo+ID4+IHRvIGJlIGVhc2llciB0byBncmFzcC4gRm9yIGFib3ZlIGV4YW1wbGVzOgo+ID4+ IAo+ID4+IAliaXRtYXBfd2VpZ2h0X2NtcCguLi4sIE4pID4gMAo+ID4+IAliaXRtYXBfd2VpZ2h0 X2NtcCguLi4sIE4pIDw9IDAKPiA+PiAJLi4uCj4gPgo+ID5iaXRtYXBfd2VpZ2h0X2NtcCgpIGNh bm5vdCBiZSBlZmZpY2llbnQuIENvbnNpZGVyIHRoaXMgZXhhbXBsZToKPiA+Cj4gPmJpdG1hcF93 ZWlnaHRfbHQoMTAwMCAwMDAwIDAwMDAgMDAwMCwgMSkgPT0gZmFsc2UKPiA+ICAgICAgICAgICAg ICAgICBeCj4gPiAgICAgICAgICAgICAgICAgc3RvcCBoZXJlCj4gPgo+ID5iaXRtYXBfd2VpZ2h0 X2NtcCgxMDAwIDAwMDAgMDAwMCAwMDAwLCAxKSA9PSAwCj4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIF4KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RvcCBo ZXJlCj4gPgo+ID5JIGFncmVlIHRoYXQgJ19ndCcgaXMgbGVzcyB2ZXJib3NlIHRoYW4gJz4nLCBi dXQgdGhlIGFkdmFudGFnZSBvZiAKPiA+J19ndCcgb3ZlciAnPicgaXMgcHJvcG9ydGlvbmFsIHRv IGxlbmd0aCBvZiBiaXRtYXAsIGFuZCBpdCBtZWFucwo+ID50aGF0IHRoaXMgQVBJIHNob3VsZCBl eGlzdC4KPiAKPiBUaGFuayB5b3UgZm9yIHRoZSBleGFtcGxlLiBJbmRlZWQsIGZvciBsZXNzLXRo YW4gdG8gYmUgZWZmaWNpZW50IGhlcmUgeW91IHdvdWxkIG5lZWQgdG8gcmVwbGFjZQo+ICBiaXRt YXBfd2VpZ2h0X2NtcCguLi4sIE4pIDwgMAo+IHdpdGgKPiAgYml0bWFwX3dlaWdodF9jbXAoLi4u LCBOLTEpIDw9IDAKCkluZGVlZCwgdGhhbmtzIGZvciBwb2ludGluZyB0byBpdC4KIAo+IEl0IHdv dWxkIHN0aWxsIGJlIG1vcmUgcmVhZGFibGUsIEkgdGhpbmsuCgpUbyBiZSBob25lc3QsIEknbSBu b3Qgc3VyZSB0aGF0CiAgICAgICAgYml0bWFwX3dlaWdodF9jbXAoLi4uLCBOLTEpIDw9IDAKd291 bGQgYmUgYW4gb2J2aW91cyByZXBsYWNlbWVudCBmb3IgdGhlIG9yaWdpbmFsCiAgICAgICAgYml0 bWFwX3dlaWdodCguLi4pIDwgTgpjb21wYXJpbmcgdG8gCiAgICAgICAgYml0bWFwX3dlaWdodF9s dCguLi4sIE4pCgpJIHRoaW5rIHRoZSBiZXN0IHRoaW5nIEkgY2FuIGRvIGlzIHRvIGFkZCBiaXRt YXBfd2VpZ2h0X2NtcCgpIGFzCnlvdSBzdWdnZXN0ZWQsIGFuZCB0dXJuIGx0IGFuZCBvdGhlcnMg dG8gYmUgd3JhcHBlcnMgb24gaXQuIFRoaXMKd2lsbCBsZXQgcGVvcGxlIGNob29zZSBhIGJldHRl ciBmdW5jdGlvbiBpbiBlYWNoIGNhc2UuCgpJIGFsc28gdGhpbmsgdGhhdCBmb3IgdjIgaXQgd291 bGQgYmUgYmV0dGVyIHRvIGRyb3AgdGhlIGNvbnZlcnNpb24KZm9yIHNob3J0IGJpdG1hcHMsIGV4 Y2VwdCBmb3Igc3dpdGNoaW5nIHRvIGJpdG1hcF9lbXB0eSgpLCBiZWNhdXNlCmluIHRoYXQgY2Fz ZSByZWFkYWJpbGl0eSB3aW5zIG92ZXIgcGVyZm9ybWFuY2U7IGlmIG5vIG9iamVjdGlvbnMuIAoK VGhhbmtzLApZdXJ5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpsaW51eC1zbnBzLWFyYyBtYWlsaW5nIGxpc3QKbGludXgtc25wcy1hcmNAbGlzdHMuaW5m cmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xp bnV4LXNucHMtYXJjCg== From mboxrd@z Thu Jan 1 00:00:00 1970 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F1F4C433EF for ; Thu, 2 Dec 2021 06:20:11 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4J4QmT2nplz3bY0 for ; Thu, 2 Dec 2021 17:20:09 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=d9ufFBZI; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::f2e; helo=mail-qv1-xf2e.google.com; envelope-from=yury.norov@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=d9ufFBZI; dkim-atps=neutral Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4J4H2X2W2Jz2ypX for ; Thu, 2 Dec 2021 11:31:46 +1100 (AEDT) Received: by mail-qv1-xf2e.google.com with SMTP id g9so21510086qvd.2 for ; Wed, 01 Dec 2021 16:31:46 -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=6mAssEZv8o/eCMWt841qPMbMDtUS/8jqauFprA197zZM5oYOFBIvv8qWwC7PLJzfXp yZ84zIT7HCYk6umOQORUkYo6XCPscvLkwVn4tIiE6i2+j5qn/7ex4vVpa6uYzdYISVBH cSxRS7O7N0T+6D8lOxxTM93u0ErNBu3mjSVvN+iHuH2CyxzWTe9zR0nQ1x6sdbDKOy2p /n7GWSH4rQEn60PEMfJrio6qJVNOhJJUsvAv/chQxcfBEn18j7+HCJQBRTrrv03RiQKb gG1CqA5S+Y4xZWDsSN6Wzsjn/9XjICFQqLBHj6EAUaOPwVkAapHMMTTeuWJ3082i60lH dYkw== X-Gm-Message-State: AOAM532Xhr76FKD+nL7tPLGICP3XQE29EMgWU6Strmx9N5XhFzDAIF1y EAxyNh19PXCp4HlQ7aQpEvI= 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=?= 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> X-Mailman-Approved-At: Thu, 02 Dec 2021 17:19:32 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Andrew Lunn , "Rafael J. Wysocki" , Catalin Marinas , Guo Ren , Christoph Lameter , Christoph Hellwig , Andi Kleen , Vincent Guittot , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , Viresh Kumar , Petr Mladek , Arnaldo Carvalho de Melo , Jens Axboe , Andy Lutomirski , Thomas Gleixner , Greg Kroah-Hartman , Randy Dunlap , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Sergey Senozhatsky , linux-crypto@vger.kernel.org, Tejun Heo , Andrew Morton , Mark Rutland , Anup Patel , linux-ia64@vger.kernel.org, David Airlie , Roy Pledge , Dave Hansen , Solomon Peachy , Stephen Rothwell , Krzysztof Kozlowski , Dennis Zhou , Matti Vaittinen , linux-alpha@vger.kernel.org, Kalle Valo , Stephen Boyd , Tariq Toukan , Dinh Nguyen , Jonathan Cameron , Ulf Hansson , Alexander Shishkin , Mike Marciniszyn , Rasmus Villemoes , Subbaraya Sundeep , Will Deacon , Sagi Grimberg , linux-csky@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, Kees Cook , Arnd Bergmann , "James E.J. Bottomley" , Vineet Gupta , Steven Rostedt , Mark Gross , Borislav Petkov , Mauro Carvalho Chehab , Thomas Bogendoerfer , "Martin K. Petersen" , David Laight , Sudeep Holla , Geetha sowjanya , Ian Rogers , kvm@vger.kernel.org, Peter Zijlstra , Amitkumar Karwar , linux-mm@kvack.org, linux-riscv@lists.infradead.org, Lee Jones , Ard Biesheuvel , Marc Zyngier , Jiri Olsa , Russell King , Andy Gross , Jakub Kicinski , Vivien Didelot , Sunil Goutham , "Paul E. McKenney" , linux-s390@vger.kernel.org, Alexey Klimov , Heiko Carstens , Hans de Goede , Nicholas Piggin , Marcin Wojtas , Vlastimil Babka , linuxppc-dev@lists.ozlabs.org, linux-mips@vger.kernel.org, Palmer Dabbelt , Daniel Vetter , Jason Wessel , Saeed Mahameed , Andy Shevchenko Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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