linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tixy@yxit.co.uk (Tixy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 09/10] ARM: kprobes: Add some benchmarking to test module
Date: Mon, 12 Sep 2011 08:09:13 +0100	[thread overview]
Message-ID: <1315811353.2255.35.camel@computer2> (raw)
In-Reply-To: <alpine.LFD.2.00.1109112241310.20358@xanadu.home>

On Sun, 2011-09-11 at 22:58 -0400, Nicolas Pitre wrote:
> On Sat, 10 Sep 2011, Tixy wrote:
> 
> > From: Jon Medhurst <tixy@yxit.co.uk>
> > 
> > These benchmarks show the basic speed of kprobes and verify the success
> > of optimisations done to the emulation of typical function entry
> > instructions (i.e. push/stmdb).
> > 
> > Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
> > ---
> 
> [...]
> 
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define wide ".w"
> > +#else
> > +#define wide
> > +#endif
> 
> I suppose you can't reuse the W() macro from arch/arm/include/asm/unified.h 
> here...
> 
> > +static int benchmark(void(*fn)(void))
> > +{
> > +	int t, n;
> > +	for (n = 1000; ; n *= 2) {
> > +		struct timeval before;
> > +		struct timeval after;
> > +		int i;
> > +
> > +		do_gettimeofday(&before);
> > +
> > +		for (i = n; i > 0; --i)
> > +			fn();
> > +
> > +		do_gettimeofday(&after);
> > +		t = after.tv_usec - before.tv_usec;
> > +		if (t < 0)
> > +			t += 1000000; /* Adjust time if it wrapped */
> > +		if (t >= 250000)
> > +			break; /* Stop once we took more than 0.25 seconds */
> > +	}
> > +	return t / (n / 1000); /* Return time in nano-seconds */
> > +};
> 
> I think that using sched_clock() here might be a better choice than 
> do_gettimeofday().  It is certainly much lower overhead and easier to 
> use.

When googling for sched_clock I came across a five year old posting [1]
by Russell saying that uses of sched_clock() for timing intervals is
broken because the range of values it gives doesn't fill all the bits in
the returned integer, leading to a discontinuity when the value wraps.

However, looking at the current implementations of sched_clock() they
seems to have full 64-bit range, and git history shows a new common
infrastructure for sched_clock being added at the end of last year. So
is the full 64-bit range now defined for the sched_clock on API on ARM?

-- 
Tixy 

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0605.0/0425.html

  reply	other threads:[~2011-09-12  7:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-10 11:04 [PATCH v2 00/10] ARM: kprobes: Add test code to kernel tree Tixy
2011-09-10 11:04 ` [PATCH v2 01/10] ARM: kprobes: Add config option for selecting the ARM kprobes tests Tixy
2011-09-10 11:04 ` [PATCH v2 02/10] ARM: kprobes: Add basic API tests Tixy
2011-09-10 11:04 ` [PATCH v2 03/10] ARM: kprobes: Framework for instruction set test cases Tixy
2011-09-12  3:01   ` Nicolas Pitre
2011-09-10 11:05 ` [PATCH v2 04/10] ARM: kprobes: Add Thumb instruction simulation " Tixy
2011-09-10 11:05 ` [PATCH v2 05/10] ARM: kprobes: Add ARM " Tixy
2011-09-10 11:05 ` [PATCH v2 06/10] ARM: kprobes: Add exports for test code Tixy
2011-09-10 11:05 ` [PATCH v2 07/10] ARM: kprobes: Add decoding table self-consistency tests Tixy
2011-09-10 11:05 ` [PATCH v2 08/10] ARM: kprobes: Add decoding table test coverage analysis Tixy
2011-09-10 11:05 ` [PATCH v2 09/10] ARM: kprobes: Add some benchmarking to test module Tixy
2011-09-12  2:58   ` Nicolas Pitre
2011-09-12  7:09     ` Tixy [this message]
2011-09-12  7:41       ` Russell King - ARM Linux
2011-09-18 11:17     ` [PATCH v3] " Tixy
2011-09-10 11:05 ` [PATCH v2 10/10] ARM: kprobes: Add introductory comment to test code Tixy
2011-09-12  3:10 ` [PATCH v2 00/10] ARM: kprobes: Add test code to kernel tree Nicolas Pitre

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=1315811353.2255.35.camel@computer2 \
    --to=tixy@yxit.co.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).