lkml.org 
[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHSET] FUSE: extend FUSE to support more operations
From
Date
On Fri, 14 Nov 2008, Tejun Heo wrote:
> Given that the number of in-flight requests are not too high, I think
> linear search is fine for now but switching it to b-tree shouldn't be
> difficult.
>
> So, pros for req/reply approach.
>
> * Less context switch per event notification.
>
> * No need for separate async notification mechanism.
>
> Cons.
>
> * More interface impedence matching from libfuse.
>
> * 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.

> Note that
> it's different from userland server keeping track. The same problem
> exists with userland based tracking but for many servers it would be
> just a bit in existing structure and we can be much more lax on
> userland. ie. actual storage backed files usually don't need
> notification at all as data is always available, so the amount of
> overhead is limited in most cases but we can't assume things like
> that for the kernel.
>
> 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.

Miklos


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