From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753380AbdK2Jgc (ORCPT ); Wed, 29 Nov 2017 04:36:32 -0500 Received: from mail-wr0-f176.google.com ([209.85.128.176]:46427 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751334AbdK2Jg3 (ORCPT ); Wed, 29 Nov 2017 04:36:29 -0500 X-Google-Smtp-Source: AGs4zMYHewjS4wVl1GguAwGlcl+DLKwBS1b7UTUusUmDrI+H2oPN4JKRI8VQ5eM4nTQ+PKOyPvIzaQ== From: Clement Courbet To: Yury Norov Cc: linux-kernel@vger.kernel.org, Andrew Morton Subject: [PATCH v5] lib: optimize cpumask_next_and() Date: Wed, 29 Nov 2017 10:35:55 +0100 Message-Id: <20171129093555.11395-1-courbet@google.com> X-Mailer: git-send-email 2.15.0.417.g466bffb3ac-goog In-Reply-To: <20171129071609.lcvcf3iezr2tcn4j@yury-thinkpad> References: <20171129071609.lcvcf3iezr2tcn4j@yury-thinkpad> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Note that on Arm (), the new c implementation still outperforms the > > old one that uses c+ the asm implementation of `find_next_bit` [3]. > What is 'c+'? Is it typo? I meant "a mix of C and asm" ~(C + asm). Rephrased. > If you find generic find_bit() on arm faster that asm one, we'd > definitely drop that piece of asm. I have this check it in my > long list. What's faster for sure is the mix (the improvement in this commit minus the possible hit from not using the ASM implementation). I can't tell whether the latter is negligible or not (I only have one ARM board to try it out), but that's definitly something to try. > This is old version of test based on get_cycles. New one is based on > ktime_get and has other minor changes. I think you'd rerun tests to > not confuse readers. New version is already in linux-next. So I'm not sure whether I should be submitting this against 'linux' or 'linux-next' ? This patch is against 'linux', so I think it should be consistent with the code around. > > #ifndef find_first_bit > > #define find_first_bit(addr, size) find_next_bit((addr), (size), 0) > > #endif > > #ifndef find_first_zero_bit > > #define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 0) > > #endif > How this change related to the find_next_and_bit? The arm header defines these symbols. Now that we're including the generic implementation in the arm headers, we need to guard this to avoid the duplicate definition. > > test_find_next_and_bit_ref > I don't understand the purpose of this. It's obviously clear that > test_find_next_and_bit cannot be slower than test_find_next_and_bit_ref Fair enough :) That was to back my claim that this commit is worth it. I've removed the "_ref" version. > For sparse bitmaps it will be like traversing zero-bitmaps. I doubt > this numbers will be representative. Do we need this test at all? It's just two lines, and gives an interesting data point. Why not keep it ?