Kay Sievers wrote: > On Thu, Oct 23, 2008 at 13:34, Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> wrote: > >> Alan Jenkins wrote: >> >>>> The in-memory rule array of a common desktop distro install took: >>>> 1151088 bytes >>>> with the token list: >>>> 109232 bytes tokens (6827 * 16 bytes), 71302 bytes buffer >>>> >>>> >>> Sounds great from a performance point of view. >>> >>> It doesn't work for me though. My simulation takes over 5 times as >>> long, and doesn't finish cleanly; i.e. there's still lots in >>> /dev/.udev/queue after the cpu usage has stopped. I'll try to track it >>> down. >>> >>> >> Sorry - the queue is cleaned up correctly. I was just too impatient. >> >> It's not a perfect test; I'm comparing >> >> a391f49d7f5433e6204f35331b81391c2d110309 - good .. >> b99028c96307e729303be8f6750418979a7488b9 - bad >> >> which includes a few more commits, though the match/action list is >> obviously the biggest one. >> >> The bad version of udevd seems to be generating two extra uevents per >> device, in addition to the ones generated by "udevadm trigger". That >> is, the output of "udevadm monitor --kernel" is three times as long! >> >> It's not a change in udevmonitor or udevtrigger; I'm still using the >> Ubuntu installed version of udevadm for testing. I really don't >> understand how this could happen. Do you have any idea? >> > > Hmm, I don't see that here. Any rules you have, which may trigger > uevents, and which may behave differently now? > grep uevent /etc/udev/rules.d/* /lib/udev/rules.d/* /dev/.udev/rules.d/* > > Kay > Nope. Drat, I can't reproduce that any more. It's still takes over five times as long, but I can't see anything unexpected happening. I tried using strace (piped through grep 'open.*uevent".*WR'). At that point it seemed to stop happening, even when I rebooted and ran it without strace. All I can think is, I must have accidentally run "udevadm trigger" twice before I started udevd. Baaa (sheepishly) Alan -- 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
