[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160805115526.GS2799@techsingularity.net>
Date: Fri, 5 Aug 2016 12:55:26 +0100
From: Mel Gorman <mgorman@...hsingularity.net>
To: James Hogan <james.hogan@...tec.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linux-MM <linux-mm@...ck.org>, Rik van Riel <riel@...riel.com>,
Vlastimil Babka <vbabka@...e.cz>,
Johannes Weiner <hannes@...xchg.org>,
Minchan Kim <minchan@...nel.org>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
LKML <linux-kernel@...r.kernel.org>,
metag <linux-metag@...r.kernel.org>
Subject: Re: [PATCH 03/34] mm, vmscan: move LRU lists to node
On Fri, Aug 05, 2016 at 11:52:57AM +0100, James Hogan wrote:
> > What's surprising is that it worked for the zone stats as it appears
> > that calling zone_reclaimable() from that context should also have
> > broken. Did anything change recently that would have avoided the
> > zone->pageset dereference in zone_reclaimable() before?
>
> It appears that zone_pcp_init() was already setting zone->pageset to
> &boot_pageset, via paging_init():
>
/me slaps self
Of course.
> > The easiest option would be to not call show_mem from arch code until
> > after the pagesets are setup.
>
> Since no other arches seem to do show_mem earily during boot like metag,
> and doing so doesn't really add much value, I'm happy to remove it
> anyway.
>
Thanks. Can I assume you'll merge such a patch or should I roll one?
> However could your change break other things and need fixing anyway?
>
Not that I'm aware of. There would have to be a node-based stat that has
meaning that early in boot to have an effect. If one happened to added
then it would need fixing but until then the complexity is unnecessary.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists