On Fri, 14 Nov 2008, Tejun Heo wrote:
quoted text
> 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.

quoted text
>  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
--
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/