From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 16 Jan 2001 07:34:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 16 Jan 2001 07:34:22 -0500 Received: from Cantor.suse.de ([194.112.123.193]:22280 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Tue, 16 Jan 2001 07:34:09 -0500 Date: Tue, 16 Jan 2001 13:34:05 +0100 From: Andi Kleen To: Ingo Molnar Cc: Andi Kleen , Linus Torvalds , dean gaudet , Linux Kernel List , Jonathan Thackray Subject: Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]] Message-ID: <20010116133405.A576@gruyere.muc.suse.de> In-Reply-To: <20010116123743.A32075@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mingo@elte.hu on Tue, Jan 16, 2001 at 01:04:22PM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 16, 2001 at 01:04:22PM +0100, Ingo Molnar wrote: > - a less radical solution would be to still map file structures to an > integer range (file descriptors) and usage-maintain files per processes, > but relax the 'allocate first non-allocated integer in the range' rule. > I'm not sure exactly how simple this is, but something like this should > work: on close()-ing file descriptors the freed file descriptors would be > cached in a list (this needs a new, separate structure which must be > allocated/freed as well). Something like: > > struct lazy_filedesc { > int fd; > struct file *file; > } More generic file -> fd mapping would be useful to speed up poll() too, because the event trigger could directly modify the poll table without a second slow walk over the whole table. So you could add another bit that tells if the fd is open or closed and share it with poll. Also in that table you could just keep a linked ordered free list and not use GFP_ANY, because getting the lowest would be rather cheap. Disadvantage is that it would need more cache and more overhead than the current scheme. [in a way it is a ugly duck like pte<->vma links] > - Best-case overhead saves us a get_unused_fd() call, which can be *very* > expensive (in terms of CPU time and cache footprint) if thousands of > files are used. If O_ANY is used mostly, then the best-case is always > triggered. Really? Does the open_fds bitmap get that big ? Maybe it just needs a faster find_next_zero_bit() @) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/