linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Tiezhu Yang' <yangtiezhu@loongson.cn>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>
Cc: "linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/3] perf bench syscall: Add close syscall benchmark
Date: Tue, 6 Sep 2022 03:30:33 +0000	[thread overview]
Message-ID: <3d1e08929fb74938998bd9aa2e370424@AcuMS.aculab.com> (raw)
In-Reply-To: <1662433577-23266-3-git-send-email-yangtiezhu@loongson.cn>

From: Tiezhu Yang
> Sent: 06 September 2022 04:06
> 
> This commit adds a simple close syscall benchmark, more syscall
> benchmarks can be added in the future.
> 
...
> 
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
>  tools/perf/bench/bench.h   |  1 +
>  tools/perf/bench/syscall.c | 11 +++++++++++
>  tools/perf/builtin-bench.c |  1 +
>  3 files changed, 13 insertions(+)
> 
> diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
> index 6cefb43..916cd47 100644
...
> diff --git a/tools/perf/bench/syscall.c b/tools/perf/bench/syscall.c
> index 746fd71..058394b 100644
> --- a/tools/perf/bench/syscall.c
> +++ b/tools/perf/bench/syscall.c
> @@ -46,6 +46,9 @@ static int bench_syscall_common(int argc, const char **argv, int syscall)
>  		case __NR_getppid:
>  			getppid();
>  			break;
> +		case __NR_close:
> +			close(dup(0));

Not really a close() test.
The dup(0) call will be significant and may take longer.

I'm also not sure that using the syscall number for the
test number is entirely sensible.

One thing I have measured in the past is the time taken
to read in an iov[] array.
This can be measured quite nicely using writev() on /dev/null.
(No copies ever happen and iov_iter() is never used.)
But you need to test a few different iov lengths.

I'm also not 100% sure how accurate/repeatable/sensible it
is to use the 'wall clock time' for 1000000 iterations.
A lot of modern cpu will dynamically change the clock speed
underneath you and other system code (like ethernet receive)
can badly perturb the results.

What you really want to use is a TSC - but they are now
useless for counting cycles.
The x86 performance counters to have a cycle counter.
I've used that to measure single calls of both library
functions and system calls.
Just 10 iterations give a 'cold cache' value and some
very consistent counts (remove real outliers).
Indeed the fastest value is really the right one.

For functions like the IP checksum you can even
show that the code is executing in the expected number
of clock cycles (usually limited by memory reads).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2022-09-06  3:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06  3:06 [PATCH 0/3] perf: Add more syscalls to benchmark Tiezhu Yang
2022-09-06  3:06 ` [PATCH 1/3] perf bench syscall: Introduce bench_syscall_common() Tiezhu Yang
2022-09-20  7:44   ` [perf bench syscall] 30463f9f35: perf-test.perf.make_fail kernel test robot
2022-09-06  3:06 ` [PATCH 2/3] perf bench syscall: Add close syscall benchmark Tiezhu Yang
2022-09-06  3:30   ` David Laight [this message]
2022-09-06  4:27     ` Tiezhu Yang
2022-09-06  3:06 ` [PATCH 3/3] perf bench syscall: Add execve " Tiezhu Yang
2022-09-28  1:06 ` [PATCH 0/3] perf: Add more syscalls to benchmark Tiezhu Yang
2022-09-28 14:15   ` Arnaldo Carvalho de Melo

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=3d1e08929fb74938998bd9aa2e370424@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=yangtiezhu@loongson.cn \
    /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;
as well as URLs for NNTP newsgroup(s).