From: Tim Bird <tim.bird@am.sony.com>
To: Daniel Walker <dwalker@fifo99.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel-team@android.com" <kernel-team@android.com>
Subject: Re: [RFC] Android Logger vs. Shared Memory FIGHT!
Date: Thu, 29 Mar 2012 10:43:35 -0700 [thread overview]
Message-ID: <4F749F47.4040500@am.sony.com> (raw)
In-Reply-To: <20120329170930.GD16476@fifo99.com>
On 03/29/2012 10:09 AM, Daniel Walker wrote:
> John Stultz commented on how gettimeofday() is more accurate that what
> is needed. Logger actually uses a less accurate, and faster, method of timing.
> The time isn't exactly apples to apples, my shared memory example is actually
> using a slower clock compared to logger.
OK - that's interesting.
>
>>
>> Tests were 60 seconds. I presume there were multiple runs and these are
>> averages. Can you provide the number of runs and the standard deviation for
>> each set?
>
>
> Test cases were 600 seconds (10 minutes) .. There were three runs.
> Here's the raw data, all in bytes per second:
>
> X86:
> Logger TSC = 70072480.0, 83911562.7, 78610971.8
> Shared Memory TSC = 460262336.0, 454204684.1, 457050682.2
>
> Logger ACPI_PM = 75523320.0, 81615111.9, 81588600.2
> Shared Memory ACPI_PM = 29688532.0, 28211029.2, 28225661.6
>
>
> ARM:
> Logger = 6985508.0, 5827587.3, 7034293.7
> Shared Memory = 12371886.7, 18362639.9, 15274489.3
> You can feel free to compute the standard deviation if you wish.
Here are the std deviations:
x86-logger-tsc: 7.4%
x86-shmem-tsc: 0.5%
x86-logger-ACPI_PM: 3.6%
x86-shmem-ACPI_PM: 2.4%
ARM-logger: 8.4%
ARM-shmem: 15.9%
Performance ratios:
x86-shmem-tsc/x86-logger-tsc -> 5.9
x86-shmem-ACPI_PM/x86-logger-ACPI_PM -> 0.36
ARM-shem/ARM-logger -> 2.3
It would be nice to understand why the ARM numbers are
not more consistent. I'll try to take a look at this next week.
Thanks for the data.
I recently started work on my own performance test suite
for logger. I'm taking the approach of simulating log
insertions based on log timings from a sampled device, and
measuring cost per message. I'm not sure when I'll finish
it, but I'll post results when I have them.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
next prev parent reply other threads:[~2012-03-29 17:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-28 21:06 [RFC] Android Logger vs. Shared Memory FIGHT! Daniel Walker
2012-03-28 21:10 ` Daniel Walker
2012-03-29 14:50 ` Daniel Walker
2012-03-29 16:25 ` Tim Bird
2012-03-29 17:09 ` Daniel Walker
2012-03-29 17:43 ` Tim Bird [this message]
2012-03-29 17:52 ` Daniel Walker
2012-03-29 18:20 ` Tim Bird
2012-03-29 18:30 ` Daniel Walker
2012-03-29 18:50 ` Alan Cox
2012-03-29 19:09 ` Daniel Walker
2012-03-29 22:19 ` Tim Bird
2012-03-29 22:58 ` Daniel Walker
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=4F749F47.4040500@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=dwalker@fifo99.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.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