From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753165AbXFDImr (ORCPT ); Mon, 4 Jun 2007 04:42:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750937AbXFDImk (ORCPT ); Mon, 4 Jun 2007 04:42:40 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:58364 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbXFDImj (ORCPT ); Mon, 4 Jun 2007 04:42:39 -0400 Date: Mon, 4 Jun 2007 10:42:27 +0200 From: Ingo Molnar To: Andrew Morton Cc: Davide Libenzi , Eric Dumazet , Linux Kernel Mailing List , Linus Torvalds , Ulrich Drepper Subject: Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core Message-ID: <20070604084227.GA29446@elte.hu> References: <46633047.1020707@cosmosbay.com> <20070603230859.5000424d.akpm@linux-foundation.org> <20070604080537.GA22898@elte.hu> <20070604080941.GA23537@elte.hu> <20070604013449.ea3acca8.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604013449.ea3acca8.akpm@linux-foundation.org> User-Agent: Mutt/1.5.14 (2007-02-12) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.0.3 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * Andrew Morton wrote: > If we just want some pseudo-private fd space for glibc to use then I'd > have thought that the existing code could be tweaked to do that: > top-down allocation, start at some high offset, etc. But apparently > there's more to it than this. top-down has the problem of rlimits: 'where is top' is a variable notion. start-at-high-offset using the existing scheme has a 'bitmap size' problem: even at 2^28 the bitmap size would be 32+ MB. per process (!). The bitmap could be allocated on demand, but that slows down the current code, uglifies it, and it would still end up somewhere looking a bit like Davide's clean new code. so, instead of trying to mesh this thing into the old fd data structures which are very much centered around and tailored to the continuous-allocation usage model, Davide cleanly separated it out into a separate data structure that fits this independently-allocated usage model well and leaves the original data structure alone. I'm strongly in favor of such clean data structure separations. Ingo