From: Daniel Walker <dwalker@fifo99.com>
To: Tim Bird <tim.bird@am.sony.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:09:30 -0700 [thread overview]
Message-ID: <20120329170930.GD16476@fifo99.com> (raw)
In-Reply-To: <4F748CF6.4010205@am.sony.com>
On Thu, Mar 29, 2012 at 09:25:26AM -0700, Tim Bird wrote:
>
> There is concern about applications leaking sensitive data into the logs,
> and a desire to possibly (in the future) support per-application logs
> for some apps. Having the code in-kernel means that things like the
> timestamp, tid and pid cannot be forged by the process. The separation
> into channels and kernel management of the read/write position provide
> an impediment to denial of service attacks.
it's unclear what problem would be caused by forging a PID, and why any
app would want to do that. It doesn't look like it would cause any
problems.
> At the moment, I'm not considering an alternative for logger that runs
> completely in user-space. Having said that, this test is certainly interesting,
> and may provide some performance numbers for logger or alternatives that would
> be useful to compare.
It's certainly up to you what you want to use, but I don't see why any
other architecture or OS would want to use logger.
> I like that you've put the gettimeofday() into the shared memory test, to
> capture the cost of the timestamp operation. Presumably, the fact that
> x86 has VDSO and ARM does not is contributing to the performance difference
> between the two platforms.
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.
>
> 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.
Daniel
next prev parent reply other threads:[~2012-03-29 17:10 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 [this message]
2012-03-29 17:43 ` Tim Bird
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=20120329170930.GD16476@fifo99.com \
--to=dwalker@fifo99.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tim.bird@am.sony.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.