Messages in this thread | | | Date | Tue, 26 Aug 2008 22:22:50 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 2/2] poll: allow f_op->poll to sleep |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 26 Aug 2008, Tejun Heo wrote: > > > > This patch converts poll/select to use custom wake up function and use > > separate triggered variable to synchronize against wake up events. > > The only added overhead is an extra function call during wake up and > > negligible. > > I don't really see the point. > > poll() isn't allowed to sleep for many reasons. Some are technical. > But the most obvious one is that a sleeping "poll()" is totally > against the whole point of polling in the first place! > > So is there some big conceptual reason to change how poll() has always > worked?
i think the point is to replace potentially fragile atomic code with less restricted 'potentially sleeping' code.
For example a GFP_KERNEL allocation will not sleep in 99% of the cases, and if it sleeps we are under such memory pressure that we dont really care all that much whether we happen to sleep in poll() or in the next userspace pagefault.
The whole ->poll() handler model would be less restricted. I dont think that's a bad idea - all our atomic contexts suffer from programmability restrictions, and people are trying to get away from them.
Plus it seems to enable FUSE some more as well - and FUSE has been spearheading a lot of filesystem development lately. FUSE is IMO the useful form of microkernels - a fast prototyping platform with a very friendly user-space programming and debugging interface. (and the fact that FUSE based filesystems can be packaged up and distributed a lot easier than kernel changes is an argument in favor of FUSE as well)
Ingo
| |