Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 18:41, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
> On Mon, 11 May 2009 18:28:20 +0200
> Kay Sievers <kay.sievers@xxxxxxxx> wrote:
>>
>> It isn't slow. It's just that bootstrapping/re-constructing something
>> later can obviously never be faster than doing it when the device is
>> created.
>
> the performance gains from doing stuff in batches is obviously well
> established; CPU caches cause that. Not saying that's a hot factor
> here, the total only takes 0.01 second after all, but "obviously" isn't
> true here.

I'm just saying that we don't need any batch, we are in the context of
the device and can do the work there, while we are doing much more and
similar stuff anyway. You can apply your cache argument there too,
because the iterator for your list would need to get the context of
every device first, and we have that already.

>> I don't know of any obvious fixes to udev, otherwise I would have
>> implemented them.
>
> there's not much to fix afaics. It'd be nice if it was the 0.06 seconds
> that Eric gets, but 0.20 isn't all that bad either.

Good.

>> > sh < /sys/initial-device-list
>>
>> And you still need to cope with the races, and bring up the event
>> listener before that.
>
> so ?

As said, you need to listen to events before you look what's already
there, otherwise you may miss stuff in-between, and you might wait for
exactly that event.

The same applies when you leave initiramfs, the in-initramfs udevd
copy is killed, and the one from the real root is started. You may
miss events in-between, and need to run a full coldplug again, not
only to apply the policy, but also to make sure that all nodes are
there. The policy can run in the background for most things just fine,
the missing node may cause trouble.

>> This is less reliable and always slower than the
>> kernel provided nodes, besides that your /sys/initial-device-list will
>> be the same amount of code we need for the node creation right away,
>> without any of the other benefits, and will require another
>> special-case tool we don't use today.
>
> it's not about the amount of code. It's about in how many useful ways
> the code can be used!

Yeah, and I mentioned many other ways this is useful, to do stuff in
parallel, to be able to rescue, and to have custom systems which do
not need a full udev at all, where many embedded systems use mbox,
which can be made much simpler.

Thanks,
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/