Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1767444AbXECWOv (ORCPT ); Thu, 3 May 2007 18:14:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1767447AbXECWOv (ORCPT ); Thu, 3 May 2007 18:14:51 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:1248 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1767444AbXECWOt (ORCPT ); Thu, 3 May 2007 18:14:49 -0400 X-AuthUser: davidel@xmailserver.org Date: Thu, 3 May 2007 15:14:48 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Ulrich Drepper cc: Davi Arnaut , Eric Dumazet , Andrew Morton , Linus Torvalds , Linux Kernel Mailing List Subject: Re: [patch 14/22] pollfs: pollable futex In-Reply-To: Message-ID: References: <20070502052235.914764000@haxent.com.br> <20070502104936.674a4b54.dada1@cosmosbay.com> <4638C37D.7050503@haxent.com.br> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3533 Lines: 76 On Thu, 3 May 2007, Ulrich Drepper wrote: > On 5/3/07, Davide Libenzi 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/