Messages in this thread | | | Subject | Re: [PATCHSET] FUSE: extend FUSE to support more operations | From | Miklos Szeredi <> | Date | Thu, 13 Nov 2008 15:48:12 +0100 |
| |
On Thu, 13 Nov 2008, Tejun Heo wrote: > poll/select/epoll can poll on massive number of files. I don't think > it's wise to have that many outstanding requests. FUSE currently uses > linear list to match replies to requests and libfuse will consume one > thread per each poll if implemented like other requests. It can be made > asynchronous from libfuse tho. > > I kind of like the original implementation tho. The f_ops->poll > interface is designed to be used like ->poll returning events if > available immediately and queue for later notification as necessary. > Notification is asynchronous and can be spurious (this actually comes > pretty handy for low level implementation). When notified, upper layer > queries the same way using ->poll. This is quite convenient for low > level implementation as the actual logic of poll can live in ->poll > proper while notifications can be scattered around places where events > can occur.
Yes, that kind of interface is nice for f_ops->poll, and for libfuse.
But for the kernel interface it's inefficient. A wake up event is 3 context switches instead of one. And that's inherent in the interface itself for no good reason.
Also there's again the question of userspace filesystem messing with the caller: your original implementation allows the userspace filesystem to block f_ops->poll() forever, which really isn't what poll/select is about.
So I'd still argue for the simple POLL-request/POLL-notify protocol on the kernel API, and possibly have the async notification similar to the kernel interface on the library API.
Implementation wise I don't care all that much, but I'd actually prefer if it was implemented using the traditional request/reply thing and optimized (possibly later) to find requests in a more efficient way than searching the linear list, which would benefit not just poll but all requests.
Miklos
| |