From: Tim Bird <tim.bird@am.sony.com>
To: Christoph Lameter <cl@linux.com>
Cc: Ezequiel Garcia <elezegarcia@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH 1/2] mm/slob: Mark zone page state to get slab usage at /proc/meminfo
Date: Tue, 23 Oct 2012 14:01:50 -0700 [thread overview]
Message-ID: <508705BE.2020403@am.sony.com> (raw)
In-Reply-To: <0000013a8f524097-4ebaed3b-0d77-4183-a6ad-f01b8855f9bf-000000@email.amazonses.com>
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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tim Bird <tim.bird@am.sony.com>
To: Christoph Lameter <cl@linux.com>
Cc: Ezequiel Garcia <elezegarcia@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH 1/2] mm/slob: Mark zone page state to get slab usage at /proc/meminfo
Date: Tue, 23 Oct 2012 14:01:50 -0700 [thread overview]
Message-ID: <508705BE.2020403@am.sony.com> (raw)
In-Reply-To: <0000013a8f524097-4ebaed3b-0d77-4183-a6ad-f01b8855f9bf-000000@email.amazonses.com>
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
next prev parent reply other threads:[~2012-10-23 21:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 12:03 [PATCH 1/2] mm/slob: Mark zone page state to get slab usage at /proc/meminfo Ezequiel Garcia
2012-10-22 12:03 ` Ezequiel Garcia
2012-10-22 14:41 ` Christoph Lameter
2012-10-22 14:41 ` Christoph Lameter
2012-10-22 14:50 ` Ezequiel Garcia
2012-10-22 14:50 ` Ezequiel Garcia
2012-10-22 17:14 ` Ezequiel Garcia
2012-10-22 17:14 ` Ezequiel Garcia
2012-10-23 18:15 ` Christoph Lameter
2012-10-23 18:15 ` Christoph Lameter
2012-10-23 18:43 ` Ezequiel Garcia
2012-10-23 18:43 ` Ezequiel Garcia
2012-10-23 20:31 ` Christoph Lameter
2012-10-23 20:31 ` Christoph Lameter
2012-10-23 21:01 ` Tim Bird [this message]
2012-10-23 21:01 ` Tim Bird
2012-10-23 21:34 ` Christoph Lameter
2012-10-23 21:34 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=508705BE.2020403@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=cl@linux.com \
--cc=elezegarcia@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.