All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-mm@kvack.org, Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 1/2] mm/memblock: expose only miminal interface to add/walk physmem
Date: Wed, 1 Jul 2020 19:28:31 +0300	[thread overview]
Message-ID: <20200701162831.GB2999146@linux.ibm.com> (raw)
In-Reply-To: <20200701153157.GC5008@osiris>

On Wed, Jul 01, 2020 at 05:31:57PM +0200, Heiko Carstens wrote:
> On Wed, Jul 01, 2020 at 06:06:43PM +0300, Mike Rapoport wrote:
> > Hi David,
> > 
> > On Wed, Jul 01, 2020 at 04:18:29PM +0200, David Hildenbrand wrote:
> > > "physmem" in the memblock allocator is somewhat weird: it's not actually
> > > used for allocation, it's simply information collected during boot, which
> > > describes the unmodified physical memory map at boot time, without any
> > > standby/hotplugged memory. It's only used on s390x and is currently the
> > > only reason s390x keeps using CONFIG_ARCH_KEEP_MEMBLOCK.
> > > 
> > > Physmem isn't numa aware and current users don't specify any flags. Let's
> > > hide it from the user, exposing only for_each_physmem(), and simplify. The
> > > interface for physmem is now really minimalistic:
> > > - memblock_physmem_add() to add ranges
> > > - for_each_physmem() / __next_physmem_range() to walk physmem ranges
> > > 
> > > Don't place it into an __init section and don't discard it without
> > > CONFIG_ARCH_KEEP_MEMBLOCK. As we're reusing __next_mem_range(), remove
> > > the __meminit notifier to avoid section mismatch warnings once
> > > CONFIG_ARCH_KEEP_MEMBLOCK is no longer used with
> > > CONFIG_HAVE_MEMBLOCK_PHYS_MAP.
> > > 
> > > While fixing up the documentation, sneak in some related cleanups. We can
> > > stop setting CONFIG_HAVE_MEMBLOCK_PHYS_MAP for s390x next.
> > 
> > As you noted in the previous version it should have been
> > CONFIG_ARCH_KEEP_MEMBLOCK ;-)
> > 
> > > Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> > > Cc: Vasily Gorbik <gor@linux.ibm.com>
> > > Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> > > Cc: Mike Rapoport <rppt@linux.ibm.com>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> > 
> > Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> > 
> > > ---
> > >  arch/s390/kernel/crash_dump.c |  6 ++--
> > >  include/linux/memblock.h      | 28 ++++++++++++++---
> > >  mm/memblock.c                 | 57 ++++++++++++++++++-----------------
> > >  3 files changed, 55 insertions(+), 36 deletions(-)
> 
> So I guess this should go via the s390 tree, since the second patch of
> this series can go only upstream if both this patch and a patch which
> is currently only on our features are merged before.
> 
> Any objections?

Not from my side.

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2020-07-01 16:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 14:18 [PATCH v2 0/2] s390/mm: don't set ARCH_KEEP_MEMBLOCK David Hildenbrand
2020-07-01 14:18 ` [PATCH v2 1/2] mm/memblock: expose only miminal interface to add/walk physmem David Hildenbrand
2020-07-01 15:06   ` Mike Rapoport
2020-07-01 15:31     ` Heiko Carstens
2020-07-01 16:28       ` Mike Rapoport [this message]
2020-07-02  7:23       ` David Hildenbrand
2020-07-03  4:48         ` Andrew Morton
2020-07-03  8:31           ` Heiko Carstens
2020-07-01 15:34     ` David Hildenbrand
2020-07-01 15:36       ` Heiko Carstens
2020-07-01 14:18 ` [PATCH v2 2/2] s390/mm: don't set ARCH_KEEP_MEMBLOCK David Hildenbrand

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=20200701162831.GB2999146@linux.ibm.com \
    --to=rppt@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.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.