Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
The logger meets linux-kernel
Posted Jan 6, 2012 10:43 UTC (Fri) by geuder (subscriber, #62854)
Overall I think I can see both points in this discussion.
Why doing some limited hard-coded stuff in the kernel if much more fexible functionality can be done in a user space daemon?
I have not worked with Android, but having seen power and other resource consumption of Maemo's daemons (udev, hal, DBus, tracker, what else...) I can understand people saying that Android took a very strict standpoint against user space daemons. Actually Maemo has syslog, but it's not installed in factory devices because it is too resource hungry.
Maybe the truth is just that one size does not fit all.
In a server the most advanced poetterish journal daemon will not consume any measurable amount of resources and the server admin might benefit from all the flexibility and functionality.
On a phone you don't even want to waste the context switches and the code size and 4 hard coded logs are just good enough.
Of course the kernel is configurable. So wouldn't that just mean that the most limited version is in the kernel (didn't Linus say that if it is used in millions of devices it deserves to be merged). But everybody from desktop upwards just configures it out, because they use a full-fledged user space daemon.
Posted Jan 8, 2012 3:08 UTC (Sun) by dmag (subscriber, #17775)
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)
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.
Posted Jan 9, 2012 2:39 UTC (Mon) by neilbrown (subscriber, #359)
No credibility without code. And measurements. :-)
Posted Jan 9, 2012 23:26 UTC (Mon) by geuder (subscriber, #62854)
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.)
Posted Jan 9, 2012 23:55 UTC (Mon) by dlang (✭ supporter ✭, #313)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds