Messages in this thread | | | Date | Fri, 14 Nov 2008 01:00:44 +0900 | From | Tejun Heo <> | Subject | Re: [PATCHSET] FUSE: extend FUSE to support more operations |
| |
Hello,
Miklos Szeredi wrote: >> * Higher overhead when poll/select finishes. Either all outstanding >> requests need to be cancelled using INTERRUPT whenever poll/select >> returns or kernel needs to keep persistent list of outstanding polls >> so that later poll/select can reuse them. The problem here is that >> kernel doesn't know when or whether they'll be re-used. We can put >> in LRU-based heuristics but it's getting too complex. > > Why not just link the outstanding poll requests into a list anchored > in 'fuse_file'? Easy to reuse, don't care about cancellation.
Ah, that's the right place.
>> Overall, I think being lazy about cancellation and let userland notify >> asynchronously would be better performance and simplicity wise. What >> do you think? > > Lazy cancellation (no cancellation, esentially) sounds good. But that > works fine with the simplified protocol. > > Think of it this way, this is what a poll event would look like with > your scheme: > > 1) -> POLL-notification > 2) <- POLL-req > 3) -> POLL-reply (revents) > > Notice, how 1) and 2) don't carry _any_ information (the notification > can be spurious, the events in the POLL request is just repeated from > the original request). All the info is in 3), so I really don't see > any reason why the above would be better than just omitting the first > two steps.
Alrighty then. I'll convert it.
Thanks.
-- tejun
| |