| |||||||||||||
The logger meets linux-kernelThe logger meets linux-kernelPosted Jan 5, 2012 0:52 UTC (Thu) by neilbrown (subscriber, #359)In reply to: The logger meets linux-kernel by dlang Parent article: The logger meets linux-kernel
By "fast" I didn't mean raw bytes-per-second speed but rather how much it slows down the rest of the system. Android needs to run on slow phones as well a quad-core monsters and we don't want to waste cycles on logs that probably aren't going to be read.
I don't think we are just talking about the stuff that a normal distro sends to syslog. Brian observed that app developers complain that other apps send too many message to the log so "their" much more important messages fall off the end of the log. This suggests a high rate of log-spam.
The kernel is *always* involved. Even if you use shared memory, who do you think it is that maps the memory into each process on the relevant page faults?
Yes: by pre-faulting large shared memory images and using futexs you could interleave logs from multiple processes with little interaction with the kernel (if each process ran on its own processor) but that doesn't fit the android security model. Each process has it's own uid and doesn't trust other processes (or at least the log system doesn't trust any of it's clients beyond the fixed API). So shared-memory logging doesn't really meet the need.
(Log in to post comments)
The logger meets linux-kernel Posted Jan 5, 2012 1:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if you want to define it, you can define any inter-process communication to involve the kernel, but most people would not talk the kernel to provide standard syslog /dev/log functionality, even though the kernel is involved.
given that they have a rather tiny fixed-size buffer (256K was mentioned), having enough logs generated to fall off the end does not really equate to that large a data rate.
But even if high performance is needed (and note that I am still not agreeing that it is), that doesn't, by itself, justify implementing something in the kernel. That's why we no longer have the tux webserver in the kernel, and there have been many other things proposed that "required" kernel level implementations for performance reasons, that ended up not going in to the kernel.
the fact that we haven't been able to get anyone to talk about data rates other than the very generic "overrunning a 256K buffer in seconds" doesn't do much to justify this going into the kernel.
I'll bet just about any linux system generates > 256k of syslog messages in 'seconds' as it boots up.
In fact, I have a server that I just rebooted, in it's first second, syslog shows >100K of message data in syslog (and this is a pretty stripped down kernel and boot, I'll bet standard distro kernels end up logging quite a bit more)
|
|||||||||||||