Hello,

Miklos Szeredi wrote:
quoted text
>> * 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.

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