Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759318AbXFGNMy (ORCPT ); Thu, 7 Jun 2007 09:12:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752706AbXFGNMq (ORCPT ); Thu, 7 Jun 2007 09:12:46 -0400 Received: from pfx2.jmh.fr ([194.153.89.55]:41268 "EHLO pfx2.jmh.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbXFGNMp (ORCPT ); Thu, 7 Jun 2007 09:12:45 -0400 Date: Thu, 7 Jun 2007 15:12:43 +0200 From: Eric Dumazet To: Kyle Moffett , Davide Libenzi Cc: Alan Cox , Ulrich Drepper , Linux Kernel Mailing List , Linus Torvalds , Andrew Morton , Ingo Molnar Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2 Message-Id: <20070607151243.22caab9e.dada1@cosmosbay.com> In-Reply-To: References: <20070606235906.72439d16@the-village.bc.nu> <20070607001932.35c9591c@the-village.bc.nu> <466741BD.20106@redhat.com> <20070607110432.73be7960@the-village.bc.nu> X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1758 Lines: 43 On Thu, 7 Jun 2007 07:59:47 -0400 Kyle Moffett wrote: > Likewise there are a massive group of other libraries (especially > user-interface and server related ones) that would really like to > have support for creating file-descriptors without the top-level > application closing them randomly (like several shells seem to). > True, shells are sometimes quite strange. For example, bash uses file descriptor 255 (FD_CLOEXEC) When it forks a new process, child gets a file table with 256 slots. At exec() time, 255 is closed but file table doesnt shrink. (shrinking is done at fork() time only) With fdmap, that means each process started by bash uses at least 256 * sizeof(list_head) bytes, ie 4096 bytes on x86_64, even if only three file-descriptors are opened (0,1,2) FD_CLOFORK should help here (BTW : current patch from Davide doesnt take this into account and might need a change in fdmap_top_open_fd()) Davide, are you sure we want FIFO for non sequential allocations ? This tends to use all the fmap slots, and not very cache friendly if an app does a lot of [open(),...,close()] things. We already got a perf drop because of RCUification of file freeing (FIFO mode instead of LIFO given by kmalloc()/kfree()) If the idea behind this FIFO was security (ie not easy for an app to predict next glibc file handle), we/glibc might use yet another FD_SECUREMODE flag, wich ORed with O_NONSEQFD would ask to fdmap_newfd() to take the tail of fmap->slist, not head. - 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/