mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Satyam Sharma" <satyam.sharma@gmail.com>
To: "Nitin Gupta" <nitingupta910@gmail.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	linux-mm-cc@laptop.org,
	linuxcompressed-devel@lists.sourceforge.net,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Richard Purdie" <richard@openedhand.com>,
	"Daniel Hazelton" <dhazelton@enter.net>,
	"Bret Towe" <magnade@gmail.com>
Subject: Re: [RFC] LZO de/compression support - take 5
Date: Mon, 28 May 2007 15:14:35 +0530	[thread overview]
Message-ID: <a781481a0705280244i1d5d315at841e4e480f0d6aa0@mail.gmail.com> (raw)
In-Reply-To: <4cefeab80705272359o16725994k7f3c01b99c5691cd@mail.gmail.com>

On 5/28/07, Nitin Gupta <nitingupta910@gmail.com> wrote:
> [...]
> Can anyone do timing measurement in kernel space only. This will
> eliminate all possible problems w.r.t usespace testing. I tried doing
> the same using get_jiffies_64() across calls to compressor in the
> 'compress-test' module but this is giving same value when measured
> just before and after calls to lzo1x_compress(). I don't know why.

Jiffies wouldn't really offer the kind of precision to serve your purpose.

> If anyone can simply measure time across lzo1x_compress() and
> lzo1x_decompress() calls in this compress-test module, then that will
> give us proper perf. figures.

I wish I had time for this myself (I'll see if I can do this tonight) ... but
anyhow, the idea is quite simply this:

cycles_t start, end;
unsigned long long diff;

start = get_cycles();
/*
 * lzo1x_compress() or
 * lzo1x_decompress() or whatever
 * on large enough input size.
 */
end = get_cycles();

diff = end - start;

That is all there is to it.

Note that get_cycles() (on x86 boxes, at least) might not be usable
or trustworthy on SMP machines unless you ensure that your code
(including the start and end timing measurements) executes on the
same particular CPU.

You could also use something like this when pin-pointing the exact
cause of the performance loss you experienced when the code was
fully cleaned up initially (before you started rolling back some stuff).

Satyam

  reply	other threads:[~2007-05-28  9:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-28  6:59 Nitin Gupta
2007-05-28  9:44 ` Satyam Sharma [this message]
2007-05-28 10:49 ` Michael-Luke Jones
2007-05-28 12:09   ` Nitin Gupta
2007-05-28 12:16     ` Michael-Luke Jones
2007-05-28 13:47       ` Pekka Enberg

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=a781481a0705280244i1d5d315at841e4e480f0d6aa0@mail.gmail.com \
    --to=satyam.sharma@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhazelton@enter.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm-cc@laptop.org \
    --cc=linuxcompressed-devel@lists.sourceforge.net \
    --cc=magnade@gmail.com \
    --cc=nitingupta910@gmail.com \
    --cc=richard@openedhand.com \
    /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®