lkml.org 
[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-11-13 17:05    [W:1.489 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site