Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Sat, May 9, 2009 at 19:11, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, 9 May 2009 18:46:10 +0200
> Kay Sievers <kay.sievers@xxxxxxxx> wrote:
>
>> On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
>> > On Sat, 9 May 2009 08:08:53 -0700
>> > Greg KH <gregkh@xxxxxxx> wrote:
>> >
>> >> > Well, guess you meant the opposite ;-)
>> >>
>> >> Heh, yes, sorry about that. ÂIt makes booting faster :)
>> >
>> > .. and I don't buy that.
>>
>> Don't buy, just try it - and you will see. :)
>
> Got some boot timing graphs for the change ?

So far, I got numbers for different options used with devtmpfs to
compare initramfs with non-initramfs. Initramfs is what all general
purpose distros need to use today, to be able to identify the disk by
LABEL/UUID/Hardware-properties. And I wanted to see how expensive the
use of initramfs is. They are posted here:
  http://lkml.org/lkml/2009/5/6/197

The "init" for intramfs is attached to the mail, mainly to illustrate
the simplification over the things we need to do today, and that there
is never a point in time where we have to delay things, because /dev
is empty during the moment we mount a fresh and empty tmpfs /dev.

To directly compare numbers for devtmpfs and non-devtmpfs, the "init"
script would need to be modified to ignore the kernel provided
devtmpfs and mount an empty tmpfs over it, and populate it, just like
we do it today. There is no theoretical chance that this can ever be
faster.

Most of the bootstrap logic we have today: mount an empty tmpfs /dev
-> add the few mandatory nodes to be able to start the bootstrap
process -> run something that reads sysfs-device-information (in the
usual case udev) -> delaying all further processing until /dev is
minimally usable to start things that rely on a working /dev, ... all
that gets basically stripped down to: "mount --move /dev /root/dev",
right at the end before we leave initramfs behind us.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/