Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based/dev

[Greg KH]

On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> Chris Friesen wrote:
> > Greg KH wrote:
> > > On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:
> > >> The question is, how fast can devtmpfs get the device list from the
> > >> kernel on bootup?  How much faster than udev?  How much slower than
> > >> static /dev?
> > >
> > > It's much faster than udev, and is equivalent to a static /dev with the
> > > exception that the group and permission settings that you are used to.
> > > udev then needs to come along and make those settings, but that's so
> > > frickin fast it's amazing.
> >
> > Earlier in the thread you indicated a 0.5sec speedup over udev.  Is that
> > really considered "much faster"?
> >
> > I do agree that it makes sense to do this, but more from an elegance
> > view than a performance one.
> 
> It's definitely more elegant, but at what cost?

You've seen the patch, you tell me :)

> For devtmpfs to be a realistic replacement for static /dev, it has to
> be comparable to static /dev in both speed and size.

Since when is this requirement necessary?  You want something for free
in both speed and size?  Well, you got it in speed, but not size, it
will take up memory that is swapable, and a tiny ammount of non-swapable
kernel memory for the code.

> WRT speed, there should be no  slowdown and it should be just as fast
> as a "tar -xp < dev.tar".

Again, where is this requirement coming from?

Have you timed devtmpfs?  Have you timed your tar extraction?  What is
the difference, and since when does anyone use tar of a static dev tree
at boot time?

> WRT size, it should not be dependent on hotplug, and instead offer
> hotplug as an option.

Um, again, who made up such a requirement?  Are you running systems
today with CONFIG_HOTPLUG disabled?  If so, how well is that working for
you?

thanks,

greg k-h
--
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/