Well, I think it's possible to get all the info in a user-space daemon, it would take several kernel calls instead of one. Given the "fast path" nature of the log, that equates directly to worse battery life.
On the other hand, I think the filesystem idea has merit. I wonder if tmpfs has disk quotas? Each app could create it's own file in /dev/shm.
- logging size could be limited by quota
- file owner is proof of ownership
- to log, the application calls gettime() and writes to memory (I assume we don't care if the app lies about time.)
- a daemon periodically reads (and zeros) the logs
Posted Jan 9, 2012 2:16 UTC (Mon) by quotemstr (subscriber, #45331)
[Link]
> Well, I think it's possible to get all the info in a user-space daemon, it would take several kernel calls instead of one.
System calls are cheap. The cost of jumping to a userspace daemon is trivial. If pumping messages over a unix socket is good enough for X11, it's good enough for logging, which needs a tiny fraction of X's throughput.
No optimization without quantification.
The logger meets linux-kernel
Posted Jan 9, 2012 2:39 UTC (Mon) by neilbrown (subscriber, #359)
[Link]
> No optimization without quantification.
No credibility without code. And measurements. :-)
The logger meets linux-kernel
Posted Jan 9, 2012 23:26 UTC (Mon) by geuder (subscriber, #62854)
[Link]
> The cost of jumping to a userspace daemon is trivial.
If you want to make a $ 30-50 phone using a 500 mAh battery the definition of trivial changes.
How many instructions does a Linux context switch take these days? I know it's architecture specific and depends on dozens of environment factors, so you are wlecome to parametrize your answer :)
> If pumping messages over a unix socket is good enough for X11
Actually that's not good enough on a small phone.
Even if logging might not be the worst problem, from my experience as a system architect I know that sometimes you have to have simple & strict rules in big organizations. If the rule is that no user space daemons, then you must stick to it even if a certain daemon would not cause real harm. If there is a dozen of teams trying to get their daemon in, it's just easier to say no to everybody than yes to to 1 team and no to 11 others.
I think even the kernel community has some rules with no discussion and no exceptions...
(I don't know whether this was the reason for Android to do what they did.)
The logger meets linux-kernel
Posted Jan 9, 2012 23:55 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
the cost of one event isn't what matters, what matters is the cost over time.
if something is 100x more expensive to run, but still only averages one cpu second per hour, it really doesn't matter.
device wakeups are similar, if you have hundreds per second it's a major problem, but once you get to around one per second the benefits of extending the sleep time further is of much less value (the average amount of time/power spent awake starts to become a fraction of the power spent 'asleep but able to wake up' and as a result, further reducing that fraction makes little practical difference.