[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1303940249.9516.366.camel@nimitz>
Date: Wed, 27 Apr 2011 14:37:29 -0700
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: Timur Tabi <timur@...escale.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Andi Kleen <andi@...stfloor.org>, Mel Gorman <mel@....ul.ie>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Nazarewicz <mina86@...a86.com>,
David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH 2/3] make new alloc_pages_exact()
On Wed, 2011-04-27 at 16:30 -0500, Timur Tabi wrote:
> Dave Hansen wrote:
> > What I really wanted in the end was a highmem-capable
> > alloc_pages_exact(), so here it is. This function can be used to
> > allocate unmapped (like highmem) non-power-of-two-sized areas of
> > memory. This is in constast to get_free_pages_exact() which can only
> > allocate from lowmem.
>
> Is there an easy way to verify that alloc_pages_exact(5MB) really does allocate
> only 5MB and not 8MB?
I'm not sure why you're asking. How do we know that the _normal_
allocator only gives us 4k when we ask for 4k? Well, that's just how it
works. If alloc_pages_exact() returns success, you know it's got the
amount of memory that you asked for, and only that plus a bit of masking
for page alignment.
Have you seen alloc_pages_exact() behaving in some other way?
> Is there some kind of function that returns the amount of
> unallocated memory, so I can do a diff?
Nope. Even if there was, it would be worthless. Calls to this might
also cause the system to swap or reclaim memory, so you might end up
with the same amount of free memory before and after the call.
-- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists