linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Doug Berger <opendmb@gmail.com>
To: David Hildenbrand <david@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Jonathan Corbet <corbet@lwn.net>, Mike Rapoport <rppt@kernel.org>,
	Borislav Petkov <bp@suse.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Muchun Song <songmuchun@bytedance.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Oscar Salvador <osalvador@suse.de>,
	Michal Hocko <mhocko@suse.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v2 2/9] mm/vmstat: show start_pfn when zone spans pages
Date: Fri, 30 Sep 2022 18:28:14 -0700	[thread overview]
Message-ID: <b86d90fe-5d57-67ec-49b7-c477924f6438@gmail.com> (raw)
In-Reply-To: <8e61d0f4-0c40-6c2d-da60-fa97e2ee7530@redhat.com>

On 9/29/2022 1:15 AM, David Hildenbrand wrote:
> On 29.09.22 00:32, Doug Berger wrote:
>> A zone that overlaps with another zone may span a range of pages
>> that are not present. In this case, displaying the start_pfn of
>> the zone allows the zone page range to be identified.
>>
> 
> I don't understand the intention here.
> 
> "/* If unpopulated, no other information is useful */"
> 
> Why would the start pfn be of any use here?
> 
> What is the user visible impact without that change?
Yes, this is very subtle. I only caught it while testing some 
pathological cases.

If you take the example system:
The 7278 device has four ARMv8 CPU cores in an SMP cluster and two 
memory controllers (MEMCs). Each MEMC is capable of controlling up to 
8GB of DRAM. An example 7278 system might have 1GB on each controller, 
so an arm64 kernel might see 1GB on MEMC0 at 0x40000000-0x7FFFFFFF and 
1GB on MEMC1 at 0x300000000-0x33FFFFFFF.

Placing a DMB on MEMC0 with 'movablecore=256M@0x70000000' will lead to 
the ZONE_MOVABLE zone spanning from 0x70000000-0x33fffffff and the 
ZONE_NORMAL zone spanning from 0x300000000-0x33fffffff.

If instead you specified 'movablecore=256M@0x70000000,512M' you would 
get the same ZONE_MOVABLE span, but the ZONE_NORMAL would now span 
0x300000000-0x32fffffff. The requested 512M of movablecore would be 
divided into a 256MB DMB at 0x70000000 and a 256MB "classic" movable 
zone start would be displayed in the bootlog as:
[    0.000000] Movable zone start for each node
[    0.000000]   Node 0: 0x000000330000000

Finally, if you specified the pathological 
'movablecore=256M@0x70000000,1G@12G' you would still have the same 
ZONE_MOVABLE span, and the ZONE_NORMAL span would go back to 
0x300000000-0x33fffffff. However, because the second DMB (1G@12G) 
completely overlaps the ZONE_NORMAL there would be no pages present in 
ZONE_NORMAL and /proc/zoneinfo would report ZONE_NORMAL 'spanned 
262144', but not where those pages are. This commit adds the 'start_pfn' 
back to the /proc/zoneinfo for ZONE_NORMAL so the span has context.

Regards,
     Doug

> 
>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>> ---
>>   mm/vmstat.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/mm/vmstat.c b/mm/vmstat.c
>> index 90af9a8572f5..e2f19f2b7615 100644
>> --- a/mm/vmstat.c
>> +++ b/mm/vmstat.c
>> @@ -1717,6 +1717,11 @@ static void zoneinfo_show_print(struct seq_file 
>> *m, pg_data_t *pgdat,
>>       /* If unpopulated, no other information is useful */
>>       if (!populated_zone(zone)) {
>> +        /* Show start_pfn for empty overlapped zones */
>> +        if (zone->spanned_pages)
>> +            seq_printf(m,
>> +                   "\n  start_pfn:           %lu",
>> +                   zone->zone_start_pfn);
>>           seq_putc(m, '\n');
>>           return;
>>       }



  reply	other threads:[~2022-10-01  1:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28 22:32 [PATCH v2 0/9] mm: introduce Designated Movable Blocks Doug Berger
2022-09-28 22:32 ` [PATCH v2 1/9] lib/show_mem.c: display MovableOnly Doug Berger
2022-09-28 22:32 ` [PATCH v2 2/9] mm/vmstat: show start_pfn when zone spans pages Doug Berger
2022-09-29  8:15   ` David Hildenbrand
2022-10-01  1:28     ` Doug Berger [this message]
2022-10-05 18:09       ` David Hildenbrand
2022-10-12 23:57         ` Doug Berger
2022-10-13 11:44           ` Michal Hocko
2022-09-28 22:32 ` [PATCH v2 3/9] mm/page_alloc: calculate node_spanned_pages from pfns Doug Berger
2022-09-28 22:32 ` [PATCH v2 4/9] mm/page_alloc.c: allow oversized movablecore Doug Berger
2022-09-28 22:32 ` [PATCH v2 5/9] mm/page_alloc: introduce init_reserved_pageblock() Doug Berger
2022-09-28 22:32 ` [PATCH v2 6/9] memblock: introduce MEMBLOCK_MOVABLE flag Doug Berger
2022-09-28 22:32 ` [PATCH v2 7/9] mm/dmb: Introduce Designated Movable Blocks Doug Berger
2022-09-28 22:33 ` [PATCH v2 8/9] mm/page_alloc: make alloc_contig_pages DMB aware Doug Berger
2022-09-28 22:33 ` [PATCH v2 9/9] mm/page_alloc: allow base for movablecore Doug Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b86d90fe-5d57-67ec-49b7-c477924f6438@gmail.com \
    --to=opendmb@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=corbet@lwn.net \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=david@redhat.com \
    --cc=f.fainelli@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=osalvador@suse.de \
    --cc=paulmck@kernel.org \
    --cc=quic_neeraju@quicinc.com \
    --cc=rdunlap@infradead.org \
    --cc=rppt@kernel.org \
    --cc=songmuchun@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).