[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1211151328430.27188@chino.kir.corp.google.com>
Date: Thu, 15 Nov 2012 13:41:24 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Jiang Liu <liuj97@...il.com>
cc: Wen Congyang <wency@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiang Liu <jiang.liu@...wei.com>,
Maciej Rutecki <maciej.rutecki@...il.com>,
Jianguo Wu <wujianguo@...wei.com>,
Chris Clayton <chris2553@...glemail.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, Mel Gorman <mgorman@...e.de>,
Minchan Kim <minchan@...nel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [PATCH] mm: fix a regression with HIGHMEM introduced by changeset
7f1290f2f2a4d
On Thu, 15 Nov 2012, Jiang Liu wrote:
> I feel that zone->present_pages has been abused. I guess it means "physical pages
> present in this zone" originally, but now sometimes zone->present_pages is used as
> "pages in this zone managed by the buddy system".
It's definition is all pages spanned by the zone that are not reserved and
unavailable to the kernel to allocate from, and the implementation of
bootmem requires that its memory be considered as "reserved" until freed.
It's used throughout the kernel to determine the amount of memory that is
allocatable in that zone from the page allocator since its reclaim
heuristics and watermarks depend on this memory being allocatable.
> So I'm trying to add a new
> field "managed_pages" into zone, which accounts for pages managed by buddy system.
> That's why I thought the clean solution is a little complex:(
>
You need to update the pgdat's node_present_pages to be consistent with
all of its zones' present_pages.
--
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