[PATCH 00/10] foundations for reserve-based allocation
- From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
- Date: Mon, 06 Aug 2007 12:29:22 +0200
In the interrest of getting swap over network working and posting in smaller
series, here is the first series.
This series lays the foundations needed to do reserve based allocation.
Traditionally we have used mempools (and others like radix_tree_preload) to
handle the problem.
However this does not fit the network stack. It is built around variable
sized allocations using kmalloc().
This calls for a different approach.
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.
The slab allocator then puts a demand of P pages on the page allocator.
So we need functions translating our demanded kmalloc space into a page
reserve limit, and then need to provide a reserve of pages.
And we need to ensure that once we hit the reserve, the slab allocator honours
the reserve's access. That is, a regular allocation may not get objects from
a slab allocated from the reserves.
There is already a page reserve, but it does not fully comply with our needs.
For example, it does not guarantee a strict level (due to the relative nature
of ALLOC_HIGH and ALLOC_HARDER). Hence we augment this reserve with a strict
limit.
Furthermore a new __GFP flag is added to allow easy access to the reserves
along-side the existing PF_MEMALLOC.
Users of this infrastructure will need to do the necessary bean counting to
ensure they stay within the requested limits.
NOTE: I have currently only implemented SLUB support, I'm still hoping
at least one of the others will die soon and save me the trouble.
--
-
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/
- Follow-Ups:
- Re: [PATCH 00/10] foundations for reserve-based allocation
- From: Matt Mackall
- Re: [PATCH 00/10] foundations for reserve-based allocation
- From: Christoph Lameter
- Re: [PATCH 00/10] foundations for reserve-based allocation
- From: Daniel Phillips
- [PATCH 02/10] mm: system wide ALLOC_NO_WATERMARK
- From: Peter Zijlstra
- [PATCH 08/10] mm: serialize access to min_free_kbytes
- From: Peter Zijlstra
- [PATCH 03/10] mm: tag reseve pages
- From: Peter Zijlstra
- [PATCH 06/10] mm: kmem_estimate_pages()
- From: Peter Zijlstra
- [PATCH 10/10] mm: __GFP_MEMALLOC
- From: Peter Zijlstra
- [PATCH 01/10] mm: gfp_to_alloc_flags()
- From: Peter Zijlstra
- [PATCH 04/10] mm: slub: add knowledge of reserve pages
- From: Peter Zijlstra
- [PATCH 05/10] mm: allow mempool to fall back to memalloc reserves
- From: Peter Zijlstra
- [PATCH 07/10] mm: allow PF_MEMALLOC from softirq context
- From: Peter Zijlstra
- [PATCH 09/10] mm: emergency pool
- From: Peter Zijlstra
- Re: [PATCH 00/10] foundations for reserve-based allocation
- Prev by Date: [PATCH 07/10] mm: allow PF_MEMALLOC from softirq context
- Next by Date: [PATCH 05/10] mm: allow mempool to fall back to memalloc reserves
- Previous by thread: Re: [PATCH] [34/58] x86_64: ia32entry adjustments
- Next by thread: [PATCH 09/10] mm: emergency pool
- Index(es):
Relevant Pages
|