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 -- 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
