Re: [libvirt] [PATCH v4 5/7] nodedev: Disable/re-enable polling on the udev fd

[...] Very good point, technically events would still get queued, we just wouldn't check and yes, we would process 1 event at a time. Not optimal, but if you look at the original code and compare it with this one performance-wise (and I hope I haven't missed anything that would render everything I write next a complete rubbish), the time complexity hasn't changed, the space complexity hasn't changed, what changed is code complexity which makes the code a bit slower due to the excessive locking and toggling the FD polling back and forth. So essentially you've got the same thing as you had before..but asynchronous. However, yes, the usage of @nevents is completely useless now (haven't realized that immediately, thanks) and a simple signalling should suffice. So how could we make it faster though? I thought more about the idea you shared in one of the previous reviews, letting the thread actually pull all the data from the monitor, to which I IIRC replied something in the sense that the event counting mechanism wouldn't allow that and it would break. Okay, let's drop the event counting. What if we now let both the udev handler thread and the event loop "poll" the file descriptor, IOW let the event loop polling the monitor fd, thus invoking udevHandleCallback which would in turn keep signalling the handler thread that there are some data. The difference now in the handler thread would be that it wouldn't blindly trust the callback about the data, because of the scheduling issue, it would keep poking the monitor itself until it gets either EAGAIN or EWOULDBLOCK from recvmsg() called in libudev, which would then be the signal to start waiting on the condition. The next an event appears, a signal from udevHandleCallback would finally have a meaning and wouldn't be ignored. This way, it's actually the handler thread who's 'the boss', as most of the signals from udevHandleCallback would be lost/NOPs. Would you agree to such an approach? Erik This magic threshold approach still wouldn't work because you don't know anything about the event at that point, you'd have to process them to actually find out whether that's a legitimate event or it's an already noted event that hasn't been processed yet, so it would still mess with your counters.