All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>,
	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 17:02:07 -0600	[thread overview]
Message-ID: <ZkKb7zuwijQXBbuB@kernel.org> (raw)
In-Reply-To: <ZkHgrTo7Sp9AxpRp@localhost.localdomain>

On Mon, May 13, 2024 at 11:43:09AM +0200, Oscar Salvador wrote:
> 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.

The populated ranges will be reported as memory and it seems that there
just will be a hole at the 3.75GB-4GB range. Not that it's important from
the sections layout perspective.

> -- 
> Oscar Salvador
> SUSE Labs
> 

-- 
Sincerely yours,
Mike.


  parent reply	other threads:[~2024-05-13 23:03 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
2024-05-13 10:12     ` Oscar Salvador
2024-05-13 23:02     ` Mike Rapoport [this message]
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=ZkKb7zuwijQXBbuB@kernel.org \
    --to=rppt@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=osalvador@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.