Miklos Szeredi wrote:

quoted text
> OK, lets do it with the original interface.  There's still room for

> optimization, though, because the _normal_ operation of poll() is

> absolutely asynchronous.

Hmm... I'm not sure I understand what you're saying but if you're

talking about optimizing async case where notification occurs while the

poller is sleeping, I don't think it really matters.  That could be

common but they're not performance sensitive path.  As select/poll users

become busy, ->poll operation becomes more and more synchronous.
If the client is using better interface like epoll, sending revents via

notification could help a bit but again the problem is that the ->poll

vfs interface is not ready for that.  e.g. How do you tell whether

->poll is for epoll polling after the notification or an asynchronous

poll(2) being called after a read(2) after the notification arrived.

There simply isn't enough information to determine when the cached

revents (no matter how short the period of caching is) can be used or

not.  One thing we can do is to invalidate the received revents value on

every file operation and then reverting to synchronous call only when

cached revents is not available, but I don't really see good

justifications for such over complexity.
Thanks.
--

tejun

--

unsubscribe notice
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/