Date:	Fri, 18 Sep 2009 17:13:28 +0200
From:	Arjan van de Ven <arjan@...radead.org>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartmann <greg@...ah.com>
Subject: Re: [PATCH] Remove broken by design and by implementation devtmpfs
  maintenance disaster

On Fri, 18 Sep 2009 16:58:28 +0200
Kay Sievers <kay.sievers@...y.org> wrote:
> > Lets be clear:
> > 1) modprobe already does some serialization (right now on the kernel
> >   side, but ideally we move that to modprobe binary so that we can
> > skip that when we can)
> 
> We only serialize symbol linking I guess, and that window got pretty
> small in recent kernels.

more than that; there's also an async_synchronize_full() function call.
I'd love to be able to move that down into modprobe.

> 
> > 2) udev today has a small design issue that is relatively easy to
> > fix. Right now, the rules call modprobe manually, each and every
> > one of them. What is needed is a MODPROBE += directive for these
> > instead of the RUN += that is done today. This is not (just) for
> > this issue here, but is essential to reduce the cost of udev. A big
> > chunk of udev cost is in doing dozens and dozens of useless
> > modprobe execs; the only way to solve this is by having a MODPROBE
> > +=. (useless because the thing they modprobe doesn't exist)
> 
> That would help in which case? Which single event does do more than a
> single modprobe call? What do you want to collect?

DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{ignore_error}+="/sbin/modprobe
$env{MODALIAS}"

I don't want to "collect". What I want is to have udev check the module
alias database directly for existence, rather than exec()ing modprobe
100 times, which then reads in that same table, etc 100 times.

if you measure things, these 100 aliases (of which maybe 5 cause a real
module to load) causing 100 execs is a rather significant chunk of
where the udev cost during boot goes.... from where I sit that makes it
worth optimizing ;)

> 
> > 3) if we move synchronization for other things to modprobe, it might
> > make sense to move the device node synchronization to it as well.
> > Exactly for the scenario you described, to get a good, generic
> > solution, that also makes sure that the permissions/ownership/etc of
> > the device node is also the right one.
> 
> How do you know what to sync against, what to wait for? I'm pretty
> sure the sync creation is much simpler and solves most of the problems
> in the right way.

it's only sync creation if the device init/registration is also sync.

for performance I suspect we need to end with an *option* to just load
all modules based on the device in the system, without waiting, and
then at the end of loading all, say, 60 modules, wait before udev
continues.

that is different than later on loading, say, the loop module by hand,
where the user expects "full synchronization". The device node is a
small part of that, and clearly a relevant part, but it all goes
together. The moment modprobe synchronizes explicitly (albeit by
default) for the device init, it can and likely could also sync the
full device creation (so including owner/acl/selinux context etc),
providing a solution to the problem you want, but including the
owner/acl bits.

I suspect you're now going "lalalala" ;-)

but I'm not saying all of this to diss your devfs code. I'm saying that
*regardless of* your code, modprobe likely needs to start doing
these synchronization steps over time.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists