Центр информации по операционным системам: Уменьшение времени загрузки Linux

Тим Берд (Tim Bird) опубликовал сегодня в LKML небольшую заметку о том, с чего можно начать в попытках уменьшения времени загрузки Linux. Недавно в листе прошло оживленное обсуждение того, что стоит сделать для уменьшения времени загрузки, в частности было много претензий на работу hotplug и подсистем USB, IEEE1394 и PCMCIA. Разработчикам потребительских электронных устройств, в то же время, удается сделать время загрузки Linux меньше одной секунды на вполне обыденных ARM чипах. Как раз об этом идущее далее письмо Тима на английском:

If you are interested in reducing bootup time for the Linux kernel,
or want to get started in this area, please read the following:

Where to start
--------------
If you are going to put some of the CELF bootup time patches on your
platform, I recommend starting with the printk-times and KFI
patches. Once you have these measurement tools on your platform,
then it's very helpful to find the delays that are useful to reduce
for your product. This will probably help your product group, in
the long run, more than some of the individual bootup time patches
available from CELF.

Supporting printk-times and KFI is usually very easy. It's already
supported on x86. It should also compile for all other architectures,
but there may be problems using it, depending on the architecture
support.

Providing a good sched-clock()
------------------------------
To use either printk-times or KFI, you basically just have to
provide an arch-specific, high granularity sched_clock() routine.
Several platforms have this already, so you
might already be in luck. If yours doesn't, it really just boils
down to using some available timer that can be polled quickly, and
that has resolution better than 1 microsecond. There are examples
lying around in the kernel source for many platforms. Note that
many platforms have a sched_clock which defaults to jiffy-resolution.
This is NOT adequate for KFI, but may help you find extremely long
delays with printk-times. Jiffies are usually either 1 millisecond
or 10 milliseconds, depending on the platform.

Since both printk-times and KFI use sched_clock() very early in
the boot sequence, the routine needs to be safe to call (even if
it returns invalid data) at any time and in any context (i.e.
interrupt context). For the TI OMAP, sched_clock was present,
but hung the machine if called before time_init(). The timer it used
was memory-mapped and thus was unavailable until after the memory
was initialized. I fixed this on my machine by simply returning
0 from sched_clock() until after time_init() was
called (I added a static "is_initialized" variable.) While this
was crude, and missed the first few milliseconds of data,
it still allowed me to focus on the rest of the bootup sequence.

printk-times and KFI information and patches are available at:

http://tree.celinuxforum.org/CelfPubWiki/InstrumentedPrintk
(printk-times used to be called "instrumented printk")
and
http://tree.celinuxforum.org/CelfPubWiki/KernelFunctionInstrumentation

General resources for reducing bootup time for the Linux kernel
are available at:
http://tree.celinuxforum.org/CelfPubWiki/BootupTimeResources

Regards, and good luck with your bootup time,
-- Tim

P.S. I have been working on an improvement to KFI which
does not require a target-side device node or control utility.
This should make it simpler to use, and possible to use
when you can't even get user-space up on your board. This
might have some debug value since KFI can provide full call
tracing when configured properly.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Обзор категории Темы новостей

Более старые новости

Новости поновей

Roman I Khimov в Четверг, 17 Февраль 2005, 00:18 |

Комментарии: 0 |

Наши новости доступны в формате RSS.