I have some time to look at this again now. I think Scott was right to question the way I handled running external programs. The "udev-exec" daemon takes a fair amount of code, and it's not easy to justify. I also suspect it would have bad effects on process placement on many-cpu systems. That said, "udev-exec" does actually improve performance. I would explain this as fork() being more efficient in processes with a smaller memory map. A multi-threaded udevd requires additional address space for each thread stack. So I'm going to try limiting the number of threads. E.g. a maximum of 2 + 2N running threads. "Running" is defined as "not waiting for an external program". The current limit on total threads would still be applied. The hope is to reduce the number of threads, while still allowing lots of parallel IO. Reducing the number of threads should help reduce overheads in general. The second reason for "udev-exec" was the "close on exec" problem of leaking irrelevant file descriptors to helper programs. Scott suggests that I make udev depend on the latest system calls, e.g. pipe2(), in 2.6.27. But I want to be able to run older kernels for testing etc! So I'll take advantage of the new calls where available. On older kernels, I'll use an RW lock to make e.g. pipe(); fcntl(fd, F_SETFD, FD_CLOEXEC) atomic against fork(). For completeness, the last reason for udev-exec was more convenient timeouts. Without udev-exec I expect they'll be a bit clunky, but it can be done. Regards 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
