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;
Date:   Tue, 14 Nov 2017 13:58:27 +0300
From:   Yury Norov <ynorov@caviumnetworks.com>
To:     Michael Ellerman <mpe@ellerman.id.au>
Cc:     linux-kernel@vger.kernel.org,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Clement Courbet <courbet@google.com>,
        Matthew Wilcox <mawilcox@microsoft.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH] lib: test module for find_*_bit() functions
Message-ID: <20171114105827.wjfv3ytuegmsgrn2@yury-thinkpad>
References: <20171109140714.13168-1-ynorov@caviumnetworks.com>
 <87r2t3wx24.fsf@concordia.ellerman.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87r2t3wx24.fsf@concordia.ellerman.id.au>
User-Agent: NeoMutt/20170113 (1.7.2)
Received-SPF: None (protection.outlook.com: cavium.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2017 10:58:40.0442 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 102dad3c-02c1-4a72-e44e-08d52b4eaa97
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3825
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Michael,

On Sun, Nov 12, 2017 at 10:33:55PM +1100, Michael Ellerman wrote:
> Yury Norov <ynorov@caviumnetworks.com> writes:
> 
> > find_bit functions are widely used in the kernel, including hot paths.
> > This module tests performance of that functions in 2 typical scenarios:
> > randomly filled bitmap with relatively equal distribution of set and
> > cleared bits, and sparse bitmap which has 1 set bit for 500 cleared bits.
> >
> > On ThunderX machine:
> >
> > 		 Start testing find_bit() with random-filled bitmap
> > [1032111.632383] find_next_bit:		240043 cycles,	164062 iterations
> > [1032111.647236] find_next_zero_bit:	312848 cycles,	163619 iterations
> > [1032111.661585] find_last_bit:		193748 cycles,	164062 iterations
> > [1032113.450517] find_first_bit:	177720874 cycles,	164062 iterations
> > [1032113.462930]
> > 		 Start testing find_bit() with sparse bitmap
> > [1032113.477229] find_next_bit:		3633 cycles,	656 iterations
> > [1032113.494281] find_next_zero_bit:	620399 cycles,	327025 iterations
> > [1032113.506723] find_last_bit:		3038 cycles,	656 iterations
> > [1032113.524485] find_first_bit:	691407 cycles,	656 iterations
> 
> Have you thought about timing it rather than using get_cycles()?
> 
> get_cycles() has the downside that it can't be compared across different
> architectures or even platforms within an architecture.

This test is written to benchmark find_bit() on the same target if algorithm
is changed. Comparing different architectures looks problematic anyway.

Different architectures may have different clock rates, and even implementations
of the function, like ARM. And many CPUs support dynamic changing of CPU speed
which will directly affect time of execution. So I don't think that direct
comparison of time across platforms would be informative without additional
precautions.

Also, other tests, like lib/interval_tree_test.c or lib/rbtree_test.c print
get_cycles() where they need to estimate performance, and it looks like common
practice.

Do you have real usecase for it?

Yury

From 1584038633434998731@xxx Tue Nov 14 10:56:00 +0000 2017
X-GM-THRID: 1583597789320519869
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread