UDev startup 30-45s or more

UDev startup 30-45s or more

[iSteve]

Greetings,
I've recently upgraded udev from 069 onto 084, and kernel from 2.6.13 
onto 2.6.15.1.

For coldplugging, I've implemented the init script mentioned on this 
mailing list, which writes "add" into uevent file for everything I want 
to have recognized by udev, ie. /sys/bus/*/devices/*/uevent 
/sys/class/*/*/uevent /sys/block/*/uevent /sys/block/*/*/uevent. This is 
approx. 700 files.

Writing into all these files already takes approx. 10-15s, but I do not 
mind that, as I believe that can be optimised later.

What I consider troublesome is that processing the queue takes over 20 
more seconds, totalling at about 30-45 seconds, which is more than all 
other init scripts altogether. I wonder, how can I optimise it? What am 
I doing wrong?

The init script creates /dev on tmpfs (the rootfs is read-only), runs 
udev --daemon and writes 'add' in correct order (as used on the init 
script posted on this mailing list) into the uevent files. Then waits 20 
seconds or until /dev/.udev/queue disappears, whichever comes first 
(unfortunately, /dev/.udev/queue doesn't disappear in the given time).

I am using udev to load modules as well, however, it has no effect if I 
have loaded them prior to running udev.

Thanks in advance for any help.
  -- iSteve


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: UDev startup 30-45s or more

[Kay Sievers]

On Tue, Feb 07, 2006 at 01:47:23PM +0100, iSteve wrote:
> Greetings,
> I've recently upgraded udev from 069 onto 084, and kernel from 2.6.13 
> onto 2.6.15.1.
> 
> For coldplugging, I've implemented the init script mentioned on this 
> mailing list, which writes "add" into uevent file for everything I want 
> to have recognized by udev, ie. /sys/bus/*/devices/*/uevent 
> /sys/class/*/*/uevent /sys/block/*/uevent /sys/block/*/*/uevent. This is 
> approx. 700 files.
> 
> Writing into all these files already takes approx. 10-15s, but I do not 
> mind that, as I believe that can be optimised later.
> 
> What I consider troublesome is that processing the queue takes over 20 
> more seconds, totalling at about 30-45 seconds, which is more than all 
> other init scripts altogether. I wonder, how can I optimise it? What am 
> I doing wrong?
> 
> The init script creates /dev on tmpfs (the rootfs is read-only), runs 
> udev --daemon and writes 'add' in correct order (as used on the init 
> script posted on this mailing list) into the uevent files. Then waits 20 
> seconds or until /dev/.udev/queue disappears, whichever comes first 
> (unfortunately, /dev/.udev/queue doesn't disappear in the given time).
> 
> I am using udev to load modules as well, however, it has no effect if I 
> have loaded them prior to running udev.

No idea. On my 2GHz laptop, the whole coldplug with running the full setup
for all ~400 devices and creating all nodes takes ~2 seconds until the queue
is completely empty.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: UDev startup 30-45s or more

[iSteve]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Kay Sievers wrote:
> No idea. On my 2GHz laptop, the whole coldplug with running the full setup
> for all ~400 devices and creating all nodes takes ~2 seconds until the queue
> is completely empty.
> 
> Kay

After toying with the udev rules, I've managed to pinpoint it to a 
single rule set; I failed to find out which rule causes it though, I 
believe it may be caused by a combination of rules.

Please note that I am _not_ running a system that has PCMCIA; I want the 
rules for udev to be generic, as I will run the same system on a 
notebook as well. The file is composed of rules from pcmciautils 
software package (for handling PCMCIA with latest kernels).

Thanks in advance for any help, it'd be nice to resolve this one:)

  -- iSteve

(Please find the attached ruleset)

[-- Attachment #2: pcmcia.rules --]
[-- Type: text/plain, Size: 1101 bytes --]

# PCMCIA devices:
#

# Very few CIS firmware entries (which we use for matching)
# are so broken that we need to read out random bytes of it
# instead of the manufactor, card or product ID. Then the
# matching is done in userspace.
ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="?*", \
		RUN+="/lib/udev/pcmcia-check-broken-cis"

# However, the "weak" matching by func_id is only allowed _after_ modprobe
# returns, so that "strong" matches have a higher priority.
ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="?*", \
		RUN+="/bin/sh -c 'echo 1 > /sys/$devpath/allow_func_id_match'"

# modprobe $modalias loads all possibly appropriate modules 
ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="?*", \ 
                RUN+="/sbin/modprobe $modalias"

# PCMCIA sockets:
#
# modprobe the pcmcia bus module so that 16-bit PCMCIA devices work
ACTION=="add", SUBSYSTEM=="pcmcia_socket", \
		RUN+="/sbin/modprobe -b pcmcia"

# if this is a PCMCIA socket which needs a resource database,
# pcmcia-socket-startup sets it up
ACTION=="add", SUBSYSTEM=="pcmcia_socket", \
		RUN+="/lib/udev/pcmcia-socket-startup"