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