On Thu, Oct 23, 2008 at 21:56, Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> wrote: > Kay Sievers wrote: >> On Thu, Oct 23, 2008 at 21:03, Kay Sievers <kay.sievers@xxxxxxxx> wrote: >>> On Thu, Oct 23, 2008 at 20:37, Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> wrote: >>> >>>> The wait should be ordered after matching KERNEL, ENV, etc. >>>> but before ATTR. >>>> >>>> Without this, WAIT_FOR_SYSFS rules will be applied unconditionally >>>> to all events. >>>> >>> Ah, nice! Thanks for finding that out. I do not have any of theses >>> rules left, as there are currently no know issues with recent kernels. >>> :) Applied. >> >> Oh, now that I expect it works for you without the long delay. :) How >> does is compare? Is it still slower? > No, that fixed it. The network interface rename problem seems to have > gone as well (!). > > I just tested it on my desktop. oprofile says it now _reduces_ cpu > cycles in udevd by 10%. Not big enough to show up in time(1), but not > bad! And it should help more on the EeePC, which has a less lavish cpu > cache. Sounds good. I've changed a few other things, which might make things faster: We cache the results of getpwnam/getgrnam() during rules parse time, some of the rules files I have here have ~700 rules with GROUP="..." keys ... We check at parse time, if we need to call fnmatch() for a key, or can just go with the much cheaper strcmp(). That seems to make a real difference with the large rules files I have. Also the snprintf() that was used compose the buffer to pass the event to a socket was _very_ expensive. We just use strlcpy() now and cache the result for the next RUN+="socket:" call. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
