Date:	Thu, 3 May 2007 15:14:48 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Ulrich Drepper <drepper@...il.com>
cc:	Davi Arnaut <davi@...ent.com.br>,
	Eric Dumazet <dada1@...mosbay.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex

On Thu, 3 May 2007, Ulrich Drepper wrote:

> On 5/3/07, Davide Libenzi <davidel@...ilserver.org> wrote:
> > 
> > I thought you were talking about the poll/epoll interface in general, and
> > the approach on how to extend it for the very few cases that ppl asks for.
> > but I see we're focusing on futexes ...
> 
> Futexes must be part of the whole approach.  If they cannot sanely be
> integrated the whole approach is more than questionable IMO.

Why is that futexes *must* be part of the "whole solution"? Ppl needs 
solutions to specific problems, not an bloated interface that, like a 
giant blob, includes everything just because it exists.



> > I'm not sure if futexes are the best approach to do that, but a way for
> > the user to signal an event into a main event loop is needed.
> 
> I haven't necessarily seen much of this demand and, as you pointed out
> yourself, there is already a completely valid and POSIX compliant way
> to achieve that.  The situation would be very different if you
> couldn't reliably implement this.

Before you try to bash a solution becuase it's costly, then you bounce 
back from another angle, and say that a solution (pipes) that uses 2 
descriptors, one file, one inode, one dentry and 4KB of kernel memory for 
each instance, is a perfectly legal solution.
The 1024 file cap is a bogus problem. If you decided to leave the POSIX 
compatibility (poll/select) for your code, to use something like epoll, it 
means already that your application is handling quite a huge amount of 
files and the 1024 cap must be out of the way. And here the cost 
associated with each file is already pretty big (inode, dentry, file, and 
buffers - for each one of them). We cannot change that cost. 



> I don't suggest this as a long term solution, it's neither nice nor
> fast.  But it is a way to achieve the goal until a real soution comes
> along.  Signals cannot serve as a justification for introducing these
> new concepts.

Fast, I think we have that pretty much covered with Ingo poiting out a few 
flaws in the numbers posted previously. Nice, I'll leave that out. 
Monolitic and interface-centric solutions, or better, solutions in search 
of a problem, do not fit the "nice" category IMO.
So, let's leave hand-waving and ugly/nice BS out of the picture, and let's 
see what is currently missing.
Epoll scales and already covers a large amount of things you may be 
interested in receiving events from. Basically everything that have a 
working f_op->poll.
The other big piece is AIO. Now you can have *another* layer on top of 
AIO, that is included in your blob interface, but why? The AIO API is 
already defined, and all you need is a way to signal the main loop that 
AIO events will be ready to be spilled out from the AIO context. And at 
that point you use the *already existing* AIO API for it. Why do you want 
to add another layer on top? What you end up doing, is pushing userspace 
code into the kernel.
The 20 lines AIO patch I posted, simply signals to an eventfd when the 
AIO context has something to be fetched.
Then we have signals and timers, covered in the other two patches. And all 
this works without being bound to an interface. Your application can just 
use poll if it does not have scalability problems.




- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists