On page allocations, SLAB and SLUB modify zone page state counters
NR_SLAB_UNRECLAIMABLE or NR_SLAB_RECLAIMABLE.
This allows to obtain slab usage information at /proc/meminfo.
Without this patch, /proc/meminfo will show zero Slab usage for SLOB.
Since SLOB discards SLAB_RECLAIM_ACCOUNT flag, we always use
NR_SLAB_UNRECLAIMABLE zone state item.
Cc: Christoph Lameter <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Matt Mackall <[email protected]>
Signed-off-by: Ezequiel Garcia <[email protected]>
---
mm/slob.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/mm/slob.c b/mm/slob.c
index fffbc82..a65e802 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -320,6 +320,9 @@ static void *slob_alloc(size_t size, gfp_t gfp, int align, int node)
sp = virt_to_page(b);
__SetPageSlab(sp);
+ /* Slob allocations are never flagged reclaimable */
+ inc_zone_page_state(sp, NR_SLAB_UNRECLAIMABLE);
+
spin_lock_irqsave(&slob_lock, flags);
sp->units = SLOB_UNITS(PAGE_SIZE);
sp->freelist = b;
@@ -361,6 +364,9 @@ static void slob_free(void *block, int size)
clear_slob_page_free(sp);
spin_unlock_irqrestore(&slob_lock, flags);
__ClearPageSlab(sp);
+
+ dec_zone_page_state(sp, NR_SLAB_UNRECLAIMABLE);
+
reset_page_mapcount(sp);
slob_free_pages(b, 0);
return;
--
1.7.8.6
On Mon, 22 Oct 2012, Ezequiel Garcia wrote:
> On page allocations, SLAB and SLUB modify zone page state counters
> NR_SLAB_UNRECLAIMABLE or NR_SLAB_RECLAIMABLE.
> This allows to obtain slab usage information at /proc/meminfo.
>
> Without this patch, /proc/meminfo will show zero Slab usage for SLOB.
>
> Since SLOB discards SLAB_RECLAIM_ACCOUNT flag, we always use
> NR_SLAB_UNRECLAIMABLE zone state item.
Hmmm... that is unfortunate. The NR_SLAB_RECLAIMABLE stat is used by
reclaim to make decisions on when to reclaim inodes and dentries.
Could you fix that to properly account the reclaimable/unreclaimable
pages?
On Mon, Oct 22, 2012 at 11:41 AM, Christoph Lameter <[email protected]> wrote:
> On Mon, 22 Oct 2012, Ezequiel Garcia wrote:
>
>> On page allocations, SLAB and SLUB modify zone page state counters
>> NR_SLAB_UNRECLAIMABLE or NR_SLAB_RECLAIMABLE.
>> This allows to obtain slab usage information at /proc/meminfo.
>>
>> Without this patch, /proc/meminfo will show zero Slab usage for SLOB.
>>
>> Since SLOB discards SLAB_RECLAIM_ACCOUNT flag, we always use
>> NR_SLAB_UNRECLAIMABLE zone state item.
>
> Hmmm... that is unfortunate. The NR_SLAB_RECLAIMABLE stat is used by
> reclaim to make decisions on when to reclaim inodes and dentries.
>
> Could you fix that to properly account the reclaimable/unreclaimable
> pages?
Sure. Does everyone agree on this?
My concern is:
1. SLOB is minimal, designed to have minimal footprint, and I'd like
to keep it that way. Of course, perhaps the change will add just a few bytes.
2. Since no SLOB user has ever complained on this...
How will this affect SLOB workings?
(I'm adding the uclinux guys, so at least they're aware of this)
Ezequiel
Hi Christoph,
On Mon, Oct 22, 2012 at 11:41 AM, Christoph Lameter <[email protected]> wrote:
> On Mon, 22 Oct 2012, Ezequiel Garcia wrote:
>
>> On page allocations, SLAB and SLUB modify zone page state counters
>> NR_SLAB_UNRECLAIMABLE or NR_SLAB_RECLAIMABLE.
>> This allows to obtain slab usage information at /proc/meminfo.
>>
>> Without this patch, /proc/meminfo will show zero Slab usage for SLOB.
>>
>> Since SLOB discards SLAB_RECLAIM_ACCOUNT flag, we always use
>> NR_SLAB_UNRECLAIMABLE zone state item.
>
... and I have a question about this.
SLUB handles large kmalloc allocations falling back
to page-size allocations (kmalloc_large, etc).
This path doesn't touch NR_SLAB_XXRECLAIMABLE zone item state.
Without fully understanding it, I've decided to implement the same
behavior for SLOB,
leaving page-size allocations unaccounted on /proc/meminfo.
Is this expected / wanted ?
SLAB, on the other side, handles every allocation through some slab cache,
so it always set the zone state.
Thanks!
Ezequiel
On Mon, 22 Oct 2012, Ezequiel Garcia wrote:
> SLUB handles large kmalloc allocations falling back
> to page-size allocations (kmalloc_large, etc).
> This path doesn't touch NR_SLAB_XXRECLAIMABLE zone item state.
Right. UNRECLAIMABLE allocations do not factor in reclaim decisions.
> Without fully understanding it, I've decided to implement the same
> behavior for SLOB,
> leaving page-size allocations unaccounted on /proc/meminfo.
>
> Is this expected / wanted ?
Yes that is fine.
> SLAB, on the other side, handles every allocation through some slab cache,
> so it always set the zone state.
Right but the caching barely has any effect at large sizes.
On Tue, Oct 23, 2012 at 3:15 PM, Christoph Lameter <[email protected]> wrote:
> On Mon, 22 Oct 2012, Ezequiel Garcia wrote:
>
>> SLUB handles large kmalloc allocations falling back
>> to page-size allocations (kmalloc_large, etc).
>> This path doesn't touch NR_SLAB_XXRECLAIMABLE zone item state.
>
> Right. UNRECLAIMABLE allocations do not factor in reclaim decisions.
>
I wasn't asking about reclaim decisions.
I think my question wasn't clear.
The issue is: with SLUB large kmallocs don't set NR_SLAB_UNRECLAIMABLE
zone item.
Thus, they don't show at /proc/meminfo. Is this okey?
Thanks!
Ezequiel
On Tue, 23 Oct 2012, Ezequiel Garcia wrote:
> The issue is: with SLUB large kmallocs don't set NR_SLAB_UNRECLAIMABLE
> zone item.
> Thus, they don't show at /proc/meminfo. Is this okey?
Yes. Other large allocations that are done directly via __get_free_pages()
etc also do not show up there. Slab allocators are intended for small
allocation and are not effective for large scale allocs. People will
use multiple different ways of acquiring large memory areas. So there is
no consistent accounting for that memory.
On 10/23/2012 1:31 PM, Christoph Lameter wrote:
> On Tue, 23 Oct 2012, Ezequiel Garcia wrote:
>
>> The issue is: with SLUB large kmallocs don't set NR_SLAB_UNRECLAIMABLE
>> zone item.
>> Thus, they don't show at /proc/meminfo. Is this okey?
> Yes. Other large allocations that are done directly via __get_free_pages()
> etc also do not show up there. Slab allocators are intended for small
> allocation and are not effective for large scale allocs. People will
> use multiple different ways of acquiring large memory areas. So there is
> no consistent accounting for that memory.
>
>
>
There's a certain irony here. In embedded, we get all worked
up about efficiencies in the slab allocators, but don't have a good
way to track the larger memory allocations. Am I missing
something, or is there really no way to track these large
scale allocations?
-- Tim
On Tue, 23 Oct 2012, Tim Bird wrote:
> There's a certain irony here. In embedded, we get all worked
> up about efficiencies in the slab allocators, but don't have a good
> way to track the larger memory allocations. Am I missing
> something, or is there really no way to track these large
> scale allocations?
We could use consistent allocator calls everywhere. But these
large allocators are rather rare. And sometimes we need pointers to page
structs and other times we use pointers to the raw memory.