Linux's implementation of poll() not scalable?
A message that is not in the archive (sent off-list or not yet received): local.mail.linux-kernel/[email protected]
In article <local.mail.linux-kernel/[email protected]> you write:
Quoted 10 lines
Quoted 3 lines · Linus Torvalds
I'd much rather have an event interface that is documented to be edge- triggered and is really _lightweight_, than have another interface that starts out with some piggy features.
Agreed (except for that 'edge-triggered' part), but I don't think
'level-triggered' implies piggy. I haven't benchmarked whetherkqueue()slows down the networking layer of FreeBSD yet; do you suspect maintaining the level-triggered structures actually is a bottleneck for them?
I really don't think it's a bottleneck. At the moment, all events are maintained on a linked list. To dequeue an event, we simply:
1. take the event on the front of the list.
2. validate event. (call filter function)
3. copy event into return array.
4. put event back on end of list.
If the `EV_ONESHOT' flag is set, we skip steps 2 & 4, and destroy the event after it is returned to the user.
(we want to wait only once for this particular event)
If the `EV_CLEAR' flag is set, we skip step 4.
(pure edge-triggered delivery)
Step 4 is pretty simple, just re-insertion back onto the queue.
If you eliminate Step 2, then you have a `correctness' issue; where the application must deal with stale events. The validation function is equally lightweight and doesn't (IMO) cause a performance problem.
Quoted 10 lines
Quoted 5 lines
... the "re-bind()" approach works very simply, and means that the overhead of testing whether the event is still active is not a generic thing that _always_ has to be done, but something where the application can basically give the kernel the information that "this time we're leaving the event possibly half-done, please re-test now".
Hmm. I don't like the extra system call, though. Any chance you'd be willing to make
get_events()take a vector of bind requests, so we can avoid the system call overhead of re-binding? (Or is that too close to kqueue for you?)
IMO, I'd think that the calls should be orthogonal. If the "get_events()" call returns an array, why shouldn't the "bind_request()" call as well? Otherwise you're only amortizing the system calls in one direction.
Quoted 5 lines
And are you sure apps will always know whether they need to rebind? Sometimes you're faced with a protocol stack which may or may not read the requests fully, and which you aren't allowed to change. It'd be nice to still have a high-performance interface that can deal with that situation.
Agreed.
--
Jonathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/