Messages in this thread |  | | Date | Fri, 21 Sep 2001 11:45:39 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
On 21-Sep-2001 Dan Kegel wrote: > Davide wrote: >> If you need to request the current status of >> a socket you've to f_ops->poll the fd. >> The cost of the extra read, done only for fds that are not "ready", is nothing >> compared to the cost of a linear scan with HUGE numbers of fds. > > Hey, wait a sec, Davide... the whole point of the Solaris /dev/poll > is that you *don't* need to f_ops->poll the fd, I think. > And in fact, Solaris /dev/poll is insanely fast, way faster than O(N).
If the fd support hints, yes.
> Consider this: what if we added to your patch logic to clear > the current read readiness bit for a fd whenever a read() on > that fd returned EWOULDBLOCK? Then we're real close to having > the current readiness state for each fd, as the /dev/poll afficianados > want. Now, there's a lot more work that'd be needed, but maybe you > get the idea of where some of us are coming from.
Then you'll fall down to /dev/poll and /dev/epoll designed for "state change" driven servers ( like rtsigs ). Instead of requesting /dev/epoll changes to make it something that is not born for, i think that the /dev/poll patch can be improved in a significant way. The numbers i've got from my test left me quite a bit deluded.
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |