| |||||||||||||
What mattersWhat mattersPosted Jan 5, 2012 18:03 UTC (Thu) by PaulMcKenney (subscriber, #9624)In reply to: The logger meets linux-kernel by dlang Parent article: The logger meets linux-kernel
Heh! Over the past couple of years, I have been repeatedly taken to task for RCU's being insufficiently aggressive about allowing the scheduler-clock tick being disabled. As in a handful of ticks at the beginning of an idle period.
So the sensitivity to CPU consumption is way higher than I would have guessed a couple of years ago. In addition, there are other well-known issues that arise when relying on a separate daemon in addition to efficiency. I have run into them many times over the years (make that decades), and I would guess that you have as well.
It is instructive to turn the question around. First, start with the assumption that the Android guys actually are competent in their area of expertise. Then ask yourself why a userspace daemon might be problematic for them.
(Log in to post comments)
What matters Posted Jan 5, 2012 18:58 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the problem is that by that logic, just about everything should be in the kernel.
I really believe that this is premature optimization and micro-benchmark optimization.
to restate an example I've posted before, several years ago at $work, the engineers ran a benchmark that showed a 60x performance improvement (from 30 seconds to .5 seconds) for a read_config() function by creating a shared memory segment and populating that rather than reading from disk.
the problem is that this benchmark was for 100,000 reads of the config file, and the real-world usage showed that this function was executed 50,000 times in an hour across >50 machines. This 6-month engineering project saved a total of 15 cpu seconds in a peak hour across 200 cores.
sometimes "it's faster", even for high multipliers of how much faster just don't matter because the function just isn't called frequently enough.
I have some firewalls that run 'inefficient' fork-for-every-connection proxies (horribly inefficient, right), but on a peak day these systems (on low-end hardware) still don't hit a loadaverage of 0.2, so the inefficiency really doesn't matter.
application logging just isn't that heavy, even on a 'slow' cell phone processor.
What matters Posted Jan 5, 2012 20:48 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]
OK, so the short version of this story is that you are not willing to assume that the Android guys are competent within their area of expertise.
Fair enough.
Just don't be surprised when others return the favor by being unwilling to assume that you are competent within your area of expertise.
What matters Posted Jan 5, 2012 21:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
when it comes to performance claims, nobody's claims of need, without the backing of numbers should be believed.
In general, this is exactly how it works in kernel development.
What matters Posted Jan 5, 2012 22:10 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]
Interesting.
How did you determine that the Android guys' avoidance of user-mode daemons was strictly due to performance issues?
What matters Posted Jan 5, 2012 22:51 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I'm basing this on their statements on l-k in the logger thread. It's always possible that I'm misunderstanding what they are meaning or missed something
What matters Posted Jan 5, 2012 23:13 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
unfortunately with my schedule for the last month and the next few weeks, I have no time to try this, but I don't think that it would be very hard to hack together a user-space replacement for the journal that listened on a few unix sockets, stored the results in a circular buffer, and provide a control socket for requesting the data get dumped out
What matters Posted Jan 6, 2012 16:35 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link] It would be really cool if you did get a chance to try this out!One caution: It is difficult to get requirements from the Android guys. Not because they are uncooperative, but because they are only conscious of some of the requirements. The rest are so second-nature to them that they don't think of them. This means that working on a suitable replacement is an iterative process, where you learn the requirements by repeatedly implementing your best guess at each point in time. John Stultz has gone through much of this process with his alarm-timers work, and he does appear to be getting close to a solution that is useful to both the Android guys and to non-smartphone software. I have been on both sides of this. Back in the 1990s, those of us at Sequent habitually wrote parallel programs, but could not describe how to do it to others. We did try, but the results were not so good. Instead, we used apprenticeship-style training: We put the new guy in a cube surrounded by people who knew parallel programming, and after a few months, the new guy would have no problem writing competent parallel code. I was on the other side while gathering wakelock requirements in 2010 and 2011. The “Avoid Thundering Herds of Timers” requirement is an example of an important requirement that was not at all obvious to me, but so obvious to the Android guys that they didn't think to state it. Sort of like you would probably not see the need to put “the acceleration of gravity at the site is 9.8 meters per second squared” when creating specs for a builder. ;–)
What matters Posted Jan 12, 2012 23:20 UTC (Thu) by Kluge (guest, #2881) [Link]
"Sort of like you would probably not see the need to put “the acceleration of gravity at the site is 9.8 meters per second squared” when creating specs for a builder. ;–)"
Does this mean that Android developers are from Mars, kernel hackers from Venus? ;-)
Mars and Venus Posted Jan 13, 2012 0:54 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link]
;-) ;-) ;-)
What matters Posted Jan 18, 2012 6:02 UTC (Wed) by kevinm (guest, #69913) [Link]
It's not the time taken by the extra cycles that matters - of course a user space daemon could keep up with the rate of message, even on a slow processor.
Rather, it's the fact that every extra cycle wasted is an extra cycle that the CPU must remain in a higher power state, and thus represents an incremental hit to the battery life. Recall in particular that context-switching from one userspace process to another requires a cache-flush on older ARM processors.
|
|||||||||||||