All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>, Yu Zhao <yuzhao@google.com>,
	David Hildenbrand <david@redhat.com>,
	Steve Capper <steve.capper@arm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V3 (RESEND) 3/3] arm64/mm: Enable vmem_altmap support for vmemmap mappings
Date: Thu, 2 Jul 2020 15:09:07 +0100	[thread overview]
Message-ID: <20200702140906.GG22241@gaia> (raw)
In-Reply-To: <1592442930-9380-4-git-send-email-anshuman.khandual@arm.com>

On Thu, Jun 18, 2020 at 06:45:30AM +0530, Anshuman Khandual wrote:
> Device memory ranges when getting hot added into ZONE_DEVICE, might require
> their vmemmap mapping's backing memory to be allocated from their own range
> instead of consuming system memory. This prevents large system memory usage
> for potentially large device memory ranges. Device driver communicates this
> request via vmem_altmap structure. Architecture needs to take this request
> into account while creating and tearing down vemmmap mappings.
> 
> This enables vmem_altmap support in vmemmap_populate() and vmemmap_free()
> which includes vmemmap_populate_basepages() used for ARM64_16K_PAGES and
> ARM64_64K_PAGES configs.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: Hsin-Yi Wang <hsinyi@chromium.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Tested-by: Jia He <justin.he@arm.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>

This looks fine to me:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

I presume this series would go into mainline via the mm tree as it
touches several architectures.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-mm@kvack.org, Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	David Hildenbrand <david@redhat.com>, Yu Zhao <yuzhao@google.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 (RESEND) 3/3] arm64/mm: Enable vmem_altmap support for vmemmap mappings
Date: Thu, 2 Jul 2020 15:09:07 +0100	[thread overview]
Message-ID: <20200702140906.GG22241@gaia> (raw)
In-Reply-To: <1592442930-9380-4-git-send-email-anshuman.khandual@arm.com>

On Thu, Jun 18, 2020 at 06:45:30AM +0530, Anshuman Khandual wrote:
> Device memory ranges when getting hot added into ZONE_DEVICE, might require
> their vmemmap mapping's backing memory to be allocated from their own range
> instead of consuming system memory. This prevents large system memory usage
> for potentially large device memory ranges. Device driver communicates this
> request via vmem_altmap structure. Architecture needs to take this request
> into account while creating and tearing down vemmmap mappings.
> 
> This enables vmem_altmap support in vmemmap_populate() and vmemmap_free()
> which includes vmemmap_populate_basepages() used for ARM64_16K_PAGES and
> ARM64_64K_PAGES configs.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: Hsin-Yi Wang <hsinyi@chromium.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Tested-by: Jia He <justin.he@arm.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>

This looks fine to me:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

I presume this series would go into mainline via the mm tree as it
touches several architectures.


  reply	other threads:[~2020-07-02 14:10 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18  1:15 [PATCH V3 (RESEND) 0/3] arm64: Enable vmemmap mapping from device memory Anshuman Khandual
2020-06-18  1:27 ` Anshuman Khandual
2020-06-18  1:15 ` Anshuman Khandual
2020-06-18  1:15 ` Anshuman Khandual
2020-06-18  1:15 ` Anshuman Khandual
2020-06-18  1:15 ` [PATCH V3 (RESEND) 1/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages() Anshuman Khandual
2020-06-18  1:27   ` Anshuman Khandual
2020-06-18  1:15   ` Anshuman Khandual
2020-06-18  1:15   ` Anshuman Khandual
2020-07-02 14:03   ` Catalin Marinas
2020-07-02 14:03     ` Catalin Marinas
2020-07-02 14:03     ` Catalin Marinas
2020-07-02 14:03     ` Catalin Marinas
2020-06-18  1:15 ` [PATCH V3 (RESEND) 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf() Anshuman Khandual
2020-06-18  1:15   ` Anshuman Khandual
2020-06-18  1:15   ` Anshuman Khandual
2020-07-02 14:07   ` Catalin Marinas
2020-07-02 14:07     ` Catalin Marinas
2020-07-02 14:07     ` Catalin Marinas
2020-07-03  6:32     ` Anshuman Khandual
2020-07-03  6:32       ` Anshuman Khandual
2020-07-03  6:32       ` Anshuman Khandual
2020-07-03 10:43     ` Michael Ellerman
2020-07-03 10:43       ` Michael Ellerman
2020-07-03 10:43       ` Michael Ellerman
2020-06-18  1:15 ` [PATCH V3 (RESEND) 3/3] arm64/mm: Enable vmem_altmap support for vmemmap mappings Anshuman Khandual
2020-06-18  1:15   ` Anshuman Khandual
2020-07-02 14:09   ` Catalin Marinas [this message]
2020-07-02 14:09     ` Catalin Marinas
2020-06-18  8:56 ` [PATCH V3 (RESEND) 0/3] arm64: Enable vmemmap mapping from device memory Mike Rapoport
2020-06-18  8:56   ` Mike Rapoport
2020-06-18  8:56   ` Mike Rapoport
2020-06-18  8:56   ` Mike Rapoport
2020-06-18  8:56   ` Mike Rapoport
2020-06-19  1:34   ` Anshuman Khandual
2020-06-19  1:46     ` Anshuman Khandual
2020-06-19  1:34     ` Anshuman Khandual
2020-06-19  1:34     ` Anshuman Khandual
2020-06-19  1:34     ` Anshuman Khandual
2020-06-23  7:39 ` Jia He
2020-06-23  7:39   ` Jia He

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=20200702140906.GG22241@gaia \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=david@redhat.com \
    --cc=hsinyi@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=steve.capper@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=yuzhao@google.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 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.