From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161301AbcHELzc (ORCPT ); Fri, 5 Aug 2016 07:55:32 -0400 Received: from outbound-smtp06.blacknight.com ([81.17.249.39]:46719 "EHLO outbound-smtp06.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934984AbcHELza (ORCPT ); Fri, 5 Aug 2016 07:55:30 -0400 Date: Fri, 5 Aug 2016 12:55:26 +0100 From: Mel Gorman To: James Hogan Cc: Andrew Morton , Linux-MM , Rik van Riel , Vlastimil Babka , Johannes Weiner , Minchan Kim , Joonsoo Kim , LKML , metag Subject: Re: [PATCH 03/34] mm, vmscan: move LRU lists to node Message-ID: <20160805115526.GS2799@techsingularity.net> References: <1467970510-21195-1-git-send-email-mgorman@techsingularity.net> <1467970510-21195-4-git-send-email-mgorman@techsingularity.net> <20160805084115.GO2799@techsingularity.net> <20160805105256.GH19514@jhogan-linux.le.imgtec.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20160805105256.GH19514@jhogan-linux.le.imgtec.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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