From: Harald Hoyer <harald@redhat.com>
To: Al Boldi <a1426z@gawab.com>
Cc: Greg KH <greg@kroah.com>, Andi Kleen <andi@firstfloor.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>,
Jan Blunck <jblunck@suse.de>,
gregkh@suse.de, Scott James Remnant <scott@ubuntu.com>
Subject: Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev
Date: Mon, 10 Aug 2009 11:22:57 +0200 [thread overview]
Message-ID: <4A7FE6F1.7030106@redhat.com> (raw)
In-Reply-To: <200908062318.05478.a1426z@gawab.com>
On 08/06/2009 10:18 PM, Al Boldi wrote:
> Greg KH wrote:
>> On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
>>> Andi Kleen wrote:
>>>> Greg KH<greg@kroah.com> writes:
>>>>> It makes the userspace boot process much simpler and easier to
>>>>> maintain, as well as providing a way to handle rescue disks and
>>>>> images trivially, and it makes the kernel _less_ dependant on the
>>>>> early userspace bootup scripts.
>>>> As a initrd less kernel user I can really only agree: getting rid
>>>> of the udev-in-initrd requirement would be a big step forward
>>>> in usability. Typically I always have to pre populate
>>>> a on disk /dev manually first to get my kernels to boot.
>>> Oh good, I thought I was the only one doing that.
>>>
>>> The reason I don't like udev is that it's just to slow; something like a
>>> 5-10s delay on each boot. No idea why it should be so slow, but it's
>>> probably probing the kernel for all available devices at boot, when it
>>> could be much quicker by probing for the device on access.
>> Like Kay stated, this sounds like a misconfiguration of your distro's
>> udev setup, as the ones I use (openSUSE and Gentoo) do not have this
>> problem at all.
>
> Maybe they are using the same trick as Ubuntu and Debian, as they run udev in
> the background to hide the slowness. Both Fedora and Mandriva run udev in
> the foreground where the slowness is visible.
On Fedora parallel to udev, readahead is running, which makes you think udev is
slow, but in the end readahead speeds up the boot process by 10%.
>
> So really, if devtmpfs compares to udev speeds then this just looks like a
> devfs comeback. Remember, devfs was really slow.
>
>
> Thanks!
>
> --
> Al
>
next prev parent reply other threads:[~2009-08-10 9:23 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 17:15 [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev Greg KH
2009-08-05 17:43 ` David Vrabel
2009-08-05 17:55 ` Greg KH
2009-08-05 18:20 ` Alan Cox
2009-08-05 18:28 ` Greg KH
2009-08-05 18:51 ` Greg KH
2009-08-06 15:46 ` Andi Kleen
2009-08-06 16:20 ` David Dillow
2009-08-06 17:10 ` Andi Kleen
2009-08-06 18:31 ` Greg KH
2009-08-07 15:47 ` Phil Turmel
2009-08-08 23:07 ` David Dillow
2009-08-10 15:39 ` Greg KH
2009-08-11 14:36 ` David Dillow
2009-08-11 14:55 ` Andi Kleen
2009-08-12 0:04 ` Marcel Holtmann
2009-08-12 0:25 ` David Dillow
2009-08-12 0:34 ` Greg KH
2009-08-12 4:31 ` Arjan van de Ven
2009-08-12 12:56 ` David Dillow
2009-08-12 13:44 ` Greg KH
2009-08-12 14:09 ` Arjan van de Ven
2009-08-12 15:25 ` Greg KH
2009-08-12 14:39 ` David Dillow
2009-08-12 15:26 ` Greg KH
2009-08-12 15:57 ` David Dillow
2009-08-12 7:31 ` Andi Kleen
2009-08-12 12:50 ` David Dillow
2009-08-12 14:07 ` Arjan van de Ven
2009-08-12 14:14 ` Andi Kleen
2009-08-10 9:04 ` Scott James Remnant
2009-08-06 17:06 ` Al Boldi
2009-08-06 17:15 ` Kay Sievers
2009-08-06 17:27 ` Al Boldi
2009-08-06 17:31 ` Kay Sievers
2009-08-06 18:36 ` Greg KH
2009-08-06 20:18 ` Al Boldi
2009-08-06 20:49 ` Greg KH
2009-08-07 4:03 ` Al Boldi
2009-08-07 4:25 ` Greg KH
2009-08-07 5:04 ` Al Boldi
2009-08-07 5:20 ` Greg KH
2009-08-07 12:49 ` Al Boldi
2009-08-07 15:13 ` Greg KH
2009-08-07 15:51 ` Chris Friesen
2009-08-07 16:06 ` Kay Sievers
2009-08-07 21:17 ` Al Boldi
2009-08-07 22:24 ` Greg KH
2009-08-08 9:14 ` Al Boldi
2009-08-08 17:11 ` Greg KH
2009-08-08 18:55 ` Al Boldi
2009-08-10 15:40 ` Greg KH
2009-08-11 3:48 ` Al Boldi
2009-08-11 4:04 ` Greg KH
2009-08-11 15:18 ` Al Boldi
2009-08-11 15:49 ` Greg KH
2009-08-11 16:04 ` Chris Friesen
2009-08-11 16:51 ` Greg KH
2009-08-12 4:25 ` Al Boldi
2009-08-10 9:01 ` Scott James Remnant
2009-08-10 12:05 ` Al Boldi
2009-08-10 12:39 ` Scott James Remnant
2009-08-10 9:22 ` Harald Hoyer [this message]
2009-08-08 22:19 ` Arjan van de Ven
2009-08-05 20:55 ` Alan Jenkins
2009-08-06 0:06 ` Greg KH
2009-08-06 0:19 ` Kay Sievers
2009-08-07 0:27 ` Greg KH
2009-08-09 12:09 ` Pavel Machek
2009-08-10 16:36 ` Greg KH
2009-08-10 15:54 ` Pavel Machek
2009-08-12 1:20 ` Kay Sievers
2009-08-12 21:33 ` Robert Schwebel
2009-08-12 22:08 ` Greg KH
2009-08-13 8:25 ` Xavier Bestel
2009-08-13 8:55 ` Robert Schwebel
2009-08-13 2:18 ` Ming Lei
2009-08-13 2:53 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A7FE6F1.7030106@redhat.com \
--to=harald@redhat.com \
--cc=a1426z@gawab.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=jblunck@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scott@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox