Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161890AbXECNqY (ORCPT ); Thu, 3 May 2007 09:46:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161893AbXECNqY (ORCPT ); Thu, 3 May 2007 09:46:24 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]:40827 "EHLO nz-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161890AbXECNqX (ORCPT ); Thu, 3 May 2007 09:46:23 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nGkA4+zD/NlCNTAM3+34oCzUTRZutB+fRWviAQux4OG1m2hXuikprbvKEyQMW9C8y2Ad/iXIIidNDtJFO2mNaxxlhDIvVrS2IiJdERaPjpZNmV5J7BMxjfaSTGPKMbE8FRJvke0WSUn+d1n9J/srMNYC1bJXoMF+O0q5Qmq5GoU= Message-ID: Date: Thu, 3 May 2007 06:46:22 -0700 From: "Ulrich Drepper" To: "Davide Libenzi" Subject: Re: [patch 14/22] pollfs: pollable futex Cc: "Davi Arnaut" , "Eric Dumazet" , "Andrew Morton" , "Linus Torvalds" , "Linux Kernel Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070502052235.914764000@haxent.com.br> <20070502095503.a06f5472.dada1@cosmosbay.com> <20070502104936.674a4b54.dada1@cosmosbay.com> <4638C37D.7050503@haxent.com.br> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1315 Lines: 30 On 5/2/07, Davide Libenzi wrote: > 99% of the fds you'll find inside an event loop you care to scale about, > are *already* fd based. You are missing the point. To get acceptable behavior of the wakeup it is necessary with this approach to open one descriptor _per thread_ for a futex. Otherwise all threads get woken upon FUTEX_WAKE. This also means you need individual epoll sets for each thread. You cannot share them anymore among all the threads in the process. > On top of that, those fds are very cheap in terms of memory They might be when they are counted in dozens. But here we are talking about the possible need to use thousands of additional file descriptors. If they are so cheap to allow thousands of descriptors with ease, why would the rlimit for files default to a small number (1024 on Fedora right now)? > And this approach is not bound to a completely new and monolitic interface. So? It's stil additional, new code for an approach which will have to be superceded real soon. That's just pure overhead to me. - 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/