[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4112a06b-bb3e-7d0f-f5b5-64e5eb5dafb4@suse.cz>
Date: Wed, 23 Oct 2019 15:25:50 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>
Cc: Mel Gorman <mgorman@...hsingularity.net>,
Waiman Long <longman@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
Roman Gushchin <guro@...com>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
Jann Horn <jannh@...gle.com>, Song Liu <songliubraving@...com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rafael Aquini <aquini@...hat.com>,
David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH] mm/vmstat: Reduce zone lock hold time when reading
/proc/pagetypeinfo
On 10/23/19 11:56 AM, Mel Gorman wrote:
> You also have to iterate over them all later in the same function. The the
> free counts are per migrate type then they would have to be iterated over
> every time.
>
> Similarly, there would be multiple places where all the counters would
> have to be iterated -- find_suitable_fallback, show_free_areas,
> fast_isolate_freepages, fill_contig_page_info, zone_init_free_lists etc.
>
> It'd be a small cost but given that it's aimed at fixing a problem with
> reading pagetypeinfo, is it really worth it? I don't think so.
I think the largest issue would be that 1) the migratetype would have to
be stored somewhere (ok, perhaps that's not an issue as free pages have
plenty of space in struct page), and 2) free page merging code
(__free_one_page()) would have to start looking at the migratetype and
fix up the counters - merging between migratetypes is not prohibited,
for good reasons. IIRC David's patch was missing that part. So I would
also prefer to avoid that.
Powered by blists - more mailing lists