On Mon, 2007-08-06 at 10:35 -0700, Daniel Phillips wrote:
> On Monday 06 August 2007 03:29, Peter Zijlstra wrote:
> > We want a guarantee for N bytes from kmalloc(), this translates to a
> > demand on the slab allocator for 2*N+m (due to the power-of-two
> > nature of kmalloc slabs), where m is the meta-data needed by the
> > allocator itself.
>
> Where does the 2* come from? Isn't it exp2(ceil(log2(N + m)))?
Given a size distribution of 2^n the worst slack space is 100% - see how
allocations of (2^m) + 1 will always need 2^(m+1) bytes.
lim_{n -> inf} (2^(n+1)/((2^n)+1)) =
2^lim_{n -> inf} ((n+1)-n) = 2^1 = 2
> Patch [3/10] adds a new field to struct page.
No it doesn't.
> I do not think this is
> necessary. Allocating a page from reserve does not make it special.
> All we care about is that the total number of pages taken out of
> reserve is balanced by the total pages freed by a user of the reserve.
And how do we know a page was taken out of the reserves?
This is done by looking at page->reserve (overload of page->index) and
this value can be destroyed as soon as its observed. It is in a sense an
extra return value.
> We do care about slab fragmentation in the sense that a slab page may be
> pinned in the slab by an unprivileged allocation and so that page may
> never be returned to the global page reserve.
A slab page obtained from the reseserve will never serve an object to an
unprivilidged allocation.
> One way to solve this is
> to have a per slabpage flag indicating the page came from reserve, and
> prevent mixing of privileged and unprivileged allocations on such a
> page.
is done.
> This patch set is _way_ less intimidating than its predecessor.
> However, I see we have entered the era of sets of patch sets, since it
> is impossible to understand the need for this allocation infrastructure
> without reading the dependent network patch set. Waiting with
> breathless anticipation.
Yeah, there were some objections to the size of it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
