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.
>  Note that

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