| |||||||||||||
Kernel Summit 2006: Embedded systems
One of those is filesystems for modern, large flash drives - filesystems like JFFS2 were never meant to scale up to that size. Current devices are pushing the limits, and there is pressure from the One Laptop Per Child project as well. Work is in progress to come up with an alternative, but details are vague at this point. Boot time is said to be getting steadily worse, and there is not a whole lot of work going into improving the situation. It was suggested that user space tends to be the larger part of the problem, but, on embedded systems, that is often not the case. Embedded systems vendors have a fair amount of control over their user spaces, and they have optimized that part of the system to the greatest extent that they can. Fixing the kernel side of the equation is a harder task, however. Much of the kernel's boot time is spent probing for devices, and there are things which can be done to improve that process. Probing in parallel is the obvious first step, though parallel probing does open the door to a lot of unpleasant race conditions. It is a solvable problem, however. Thomas Gleixner talked a bit about timers. In particular, the embedded systems vendors have a real need for the dynamic tick code. This patch, often called "dyntick," does away with the regular clock tick in favor of explicitly scheduled timer interrupts when the kernel determines that it will need to be awakened. Eliminating the clock tick cuts power consumption, especially in situations where the CPU would otherwise be sleeping. Thomas noted that many systems can, with dyntick, run with about 1.5 actual ticks per second - a significant reduction from the default 250Hz clock rate. But one must first kill the GNOME clock applet, which, for some reason, requires a 100Hz tick of its own. Linus noted that the ARM architecture has offered a dynamic tick feature for some time. The current version of the dyntick patch differs significantly from the ARM implementation, but the ARM maintainers are evidently willing to move over to it. So there is no real reason for keeping dyntick out of the kernel. Matt talked briefly about kernel code size. It turns out that, in recent times, the size of the i386 kernel has actually gone down slightly. That reduction is mainly the result of Matt's work in shrinking code, eliminating unnecessary inline functions, and providing replacement code (such as the SLOB allocator) for kernel subsystems whose complexity is unneeded in an embedded environment. There was no discussion of one of the ongoing problems in this area: getting embedded systems developers to participate in the community and contribute improvements back to the mainline kernel.
(Log in to post comments)
Kernel Summit 2006: dynticks Posted Jul 19, 2006 23:54 UTC (Wed) by mingo (subscriber, #31122) [Link] FYI, the 'generic dyntick' patch referenced to by Thomas Gleixner is completely different from the old dyntick patch (linked to in this article), done by Con Kolivas & co.
Our new code is a complete rewrite, ontop of the GTOD + high-res-timers code, while Con's code implemented a whole new separate infrastructure for dynticks. It turns out that generic dyntick can be implemented in a rather elegant way via the pure use of kernel/hrtimers.c APIs and via some simple callbacks from the scheduler code.
We reused bits of Con's patch: for example the 'timer top' functionality to figure out the most active timers in a running system. We also obviously learned from the experiences of the old dyntick patch - so the new code is SMP-friendly from grounds up, etc.
We also reused the name :-) We didnt feel like naming it dynticks2, beacuse it's not a parallel competition to dynticks (like suspend2 is to suspend) but it is a reimplementation and replacement.
Kernel Summit 2006: dynticks Posted Jul 23, 2006 17:38 UTC (Sun) by ChristopheC (guest, #28570) [Link] Thanks ! Good to know it is on the way to mainline. Is it going in for 2.6.19 ?
Also, will the ACPI patches that were part of Con's patchset be included too ? Con wasn't the author (it was Dominik Brodowski), but IIRC correctly they allowed power savings by using the C3 (and C2 ?) states more aggressively.
Kernel Summit 2006: dynticks Posted Jul 25, 2006 14:33 UTC (Tue) by tglx (subscriber, #31301) [Link] Yes, I'm working on that. Dominik resent the patches a few weeks ago and they will be integrated.
Kernel Summit 2006: Embedded systems Posted Jul 20, 2006 23:44 UTC (Thu) by wookey (subscriber, #5501) [Link] Is this talk online anywhere? I would be interested to read more. Maybe I should start going to OLS. Willy said he was trying to get them to move it to Cambridge - that would be handy :-) Part of the problem with embedded developers not being good at contributing back to mainline is that they are usually suffering terribly from being stuck on a product treadmill with high pressure deadlines so tidying up patches to a state adequate for mainline inclusion often gets pushed back down the todo list (and then they are stale so you have to update then now too). At least some of the time developers are also relatively new to the whole thing and are far too embarrassed to show their code to _real_ kernel developers (not realising that if they are any good it will probably be rather more acceptable than they think it is). They are also often working with super-ancient kernels and code so mainline is not terribly interested in their changes I have certainly seen all of these effects in action, and I am, myself, an example of the genre: I have been sadly remiss about getting something am (partly) responsible for (YAFFS) into mainline. First it was too new, obscure and experimental, then we did a new version, and then we got stuck in a state where we were out of step with the MTD API for an embarassingly long time (about a year). And of course there is always that pressure of other things people are clamouring to have done, or a dead hard drive or a broken webserver, that mean today is never the week to sort out the current code, check it works with latest MTD and kernel and send it in. We did actually try and get stuff ready for 2.6.18 but missed. So we really might finally make 2.6.19. I hope so, it's been far too long. YAFFS2 may be helpful with regard to the large flash drives issue, although it too was originally designed when 128MB was a lot of flash (back in 2002), and it currently maxes out at 8GB (per partition) which is probably already too small for some people. It does at least now have checkpointing so if you shut down properly then there is no need to rescan the flash at startup which can improve boot times by about a factor of 100. It is possible to make this work for non-safe shutdowns too, but that is not work that has currently been put into the filesystem, although it has been implemented in proof-of-concept form as descibed in this paper. I haven't looked recently to see how this compares with current JFFS2/3, which of course I ought to do...Hopefully dwmw2 will be along in a mo to update me
Kernel Summit 2006: Embedded systems Posted Jul 25, 2006 3:06 UTC (Tue) by roelofs (guest, #2599) [Link] Part of the problem with embedded developers not being good at contributing back to mainline is that they are usually suffering terribly from being stuck on a product treadmill with high pressure deadlines ...Yup. Also getting approvals, from either legal or management or both. YAFFS2 ... currently maxes out at 8GB (per partition) which is probably already too small for some people. Yup. There are already IDE flash drives (both interface and form factor) of at least 32GB (~US$600), and I'm aware of at least one application where splitting that isn't an option. Greg
Slow probing Posted Jul 27, 2006 15:30 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] Much of the kernel's boot time is spent probing for devices....Could the kernel have a list of devices, prepared from a previous probe, which the kernel just takes as correct, to streamline that part? Obviously it would need to be updated for new or removed hardware, but if the list is wrong, on my head be it. Since this would lead to a spate of ``my system won't boot'' complaints, have it require a kernel argument, to restrict its use to those with something of a clue. I know I'd really appreciate it when I'm optimizing a kernel, and rebooting every few minutes.
Slow probing Posted Jul 27, 2006 17:30 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] this is exactly why I compile custom kernels for each machine, and only include drivers for hardware that exists (or has a high liklyhood of being added)
the one (partial) exception is my laptop, which is relativly slow anyway :-( but is mroe likly to have new hardware plugged into it in the form of pcmcia cards or strange USB devices.
|
|||||||||||||