Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/