From: Oscar Salvador <osalvador@suse.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [LSF/MM/BFP TOPIC] Deprecate SPARSEMEM and have only SPARSEMEM_VMEMMAP
Date: Mon, 13 May 2024 11:43:09 +0200 [thread overview]
Message-ID: <ZkHgrTo7Sp9AxpRp@localhost.localdomain> (raw)
In-Reply-To: <Zj6ZzmpBr3BgLeaA@casper.infradead.org>
On Fri, May 10, 2024 at 11:03:58PM +0100, Matthew Wilcox wrote:
> I'm a little concerned about having this conversation without the
> affected architecture maintainers in the room. However, I can speak to
> PA-RISC.
Yes, having the architecture maintainers would be great.
> Early models have a dense memory layout and we need not be concerned
> with them. I'm not quite sure about the PA-7200 to PA-8500 ccio based
> machines, would need to do some research. For the PA-8500+ astro based
> machines, the 256MB that would be in the range 3.75GB to 4GB is
> relocated to 67.75-68GB to leave space for PCI mmio. So if you have
> a machine with 8GB of memory (fairly typical for a J6000 machine),
> you'd have three ranges of memory:
>
> 0-3.75GB
> 4-8GB
> 67.75-68GB
>
> and I'd like to see an analysis of how laying out memmap would differ
> for those machines.
Maybe Mike can prove me wrong, but I assume that memblock will report
the above ranges as memory, and the 3.75GB to 4GB as somewhat reserved.
Then, we only mark those sections falling within the ranges reported as
having memory by memblock as present, and we only populate the memmap
for present sections.
So, those ranges from above will be represented by present sections
and hence with the vmemmap populated, and anything that falls off
will not.
I am not sure if I got your concern right though.
> The PA-8800+ pluto chipset does something similar, except it
> supports more memory and more PCI mmio, so a 32GB rp3440 would have
> a memmap:
>
> 0-3GB
> 4-32GB
> 259-260GB
>
> I think this would actually work better as three zones rather than
> three sections. It might match quite well with the TAO proposal.
But those are not really sections, are they? But rather memory ranges.
Checking the code from parisc, sections are at 128MB granularity.
So you will have
0-3GB -> 0 .. 23 section (memmap populated)
4-32GB -> 31 .. 255 section (memmap populated)
259-260GB -> 2071 .. 2079 section (memmap populated)
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2024-05-13 9:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 9:03 [LSF/MM/BFP TOPIC] Deprecate SPARSEMEM and have only SPARSEMEM_VMEMMAP Oscar Salvador
2024-05-10 22:03 ` Matthew Wilcox
2024-05-13 9:43 ` Oscar Salvador [this message]
2024-05-13 10:12 ` Oscar Salvador
2024-05-13 23:02 ` Mike Rapoport
2024-05-12 13:45 ` Mike Rapoport
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=ZkHgrTo7Sp9AxpRp@localhost.localdomain \
--to=osalvador@suse.de \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=willy@infradead.org \
/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).