| |||||||||||||
The logger meets linux-kernelThe logger meets linux-kernelPosted Jan 5, 2012 2:08 UTC (Thu) by mezcalero (subscriber, #45103)In reply to: The logger meets linux-kernel by dw Parent article: The logger meets linux-kernel
Oh yeah, Jon, this is a major bug in your article. SCM_CREDENTIALS does exactly what is needed and is used by default by the journal to enhance every single journal entry with reliable information about what process sent it.
(Log in to post comments)
The logger meets linux-kernel Posted Jan 6, 2012 10:43 UTC (Fri) by geuder (subscriber, #62854) [Link]
Good point! I wasn't aware of SCM_CREDENTIALS either, must have been a while that I read unix(7) carefully the last time.
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.
The logger meets linux-kernel Posted Jan 8, 2012 3:08 UTC (Sun) by dmag (subscriber, #17775) [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. 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.
The logger meets linux-kernel 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 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.
|
|||||||||||||