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
Date: Tue, 14 Nov 2017 13:58:27 +0300 [thread overview]
Message-ID: <20171114105827.wjfv3ytuegmsgrn2@yury-thinkpad> (raw)
In-Reply-To: <87r2t3wx24.fsf@concordia.ellerman.id.au>
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
next prev parent reply other threads:[~2017-11-14 10:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 14:07 Yury Norov
2017-11-09 14:33 ` Clement Courbet
2017-11-09 23:15 ` Andrew Morton
2017-11-10 10:45 ` Alexey Dobriyan
2017-11-14 10:07 ` Yury Norov
2017-11-14 23:55 ` Andrew Morton
2017-11-12 11:33 ` Michael Ellerman
2017-11-14 10:58 ` Yury Norov [this message]
2017-11-21 8:38 ` Geert Uytterhoeven
2017-11-24 14:30 ` Yury Norov
2017-11-24 15:46 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171114105827.wjfv3ytuegmsgrn2@yury-thinkpad \
--to=ynorov@caviumnetworks.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=courbet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mawilcox@microsoft.com \
--cc=mpe@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®