Messages in this thread | | | Date | Thu, 29 Mar 2012 09:25:26 -0700 | From | Tim Bird <> | Subject | Re: [RFC] Android Logger vs. Shared Memory FIGHT! |
| |
On 03/29/2012 07:50 AM, Daniel Walker wrote: > On Wed, Mar 28, 2012 at 02:06:32PM -0700, Daniel Walker wrote: >> >> >> I went to Linaro Connect a few weeks ago. While I was there they held a >> meeting with some of the Android developers and some community developers. >> During the meeting Brian Swetland and Tim Bird were talking about upstreaming >> Android's logger kernel changes. Brian mentioned that logger was in the kernel >> for “performance reasons”.
... > I made no attempt to address any security issues in logger. Since logger has > no security built into it currently. There are at least two ways to provide security > to the shared memory interface that I know of, but I'm not planning to discuss them in > this analysis.
At the mainlining meeting at Connect, we discussed some of the security and robustness issues with logger, that would affect whether a user-space-only solution would work.
See the etherpad at: http://summit.linaro.org/lcq1-12/meeting/20039/linaro-kernel-q112-android-mainlining-f2f-2/
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.
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.
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.
I'm a little worried about caching effects for this test, since it seems like it would run in a very tight loop (with the exception of the gettimeofday() or the call to logger.
> x86: > +-----------------+----------------------+-------------------+ > |Clocksource | TSC | ACPI_PM | > +-----------------+----------------------+-------------------+ > |Shared Memory | 457172567.4B/s | 28708407.6B/s | > +-----------------+----------------------+-------------------+ > |Android Logger | 77531671.5B/s | 79575677.3B/s | > +-----------------+----------------------+-------------------+ > > ARM: > +-----------------+----------------------+ > |Shared Memory | 15336338.6B/s | > +-----------------+----------------------+ > |Android Logger | 6615796.3B/s | > +-----------------+----------------------+
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?
Thanks, -- Tim
============================= Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment =============================
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |