From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Justin He <Justin.He@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Steve Capper <Steve.Capper@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Dave Hansen <dave.hansen@linux.intel.com>,
Kees Cook <keescook@chromium.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
Date: Wed, 29 Jul 2020 17:12:54 +0300 [thread overview]
Message-ID: <20200729141254.GE3672596@linux.ibm.com> (raw)
In-Reply-To: <170d7861-4df8-ecaf-dbdd-9e9a4a832f8f@redhat.com>
On Wed, Jul 29, 2020 at 03:03:04PM +0200, David Hildenbrand wrote:
> On 29.07.20 15:00, Mike Rapoport wrote:
> > On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote:
> >>>
> >>> There is still large gap with ARM64_64K_PAGES, though.
> >>>
> >>> As for SPARSEMEM without VMEMMAP, are there actual benefits to use it?
> >>
> >> I was asking myself the same question a while ago and didn't really find
> >> a compelling one.
> >
> > Memory overhead for VMEMMAP is larger, especially for arm64 that knows
> > how to free empty parts of the memory map with "classic" SPARSEMEM.
>
> You mean the hole punching within section memmap? (which is why their
> pfn_valid() implementation is special)
Yes, arm (both 32 and 64) do this. And for smaller systems with a few
memory banks this is very reasonable to trade slight (if any) slowdown
in pfn_valid() for several megs of memory.
> (I do wonder why that shouldn't work with VMEMMAP, or is it simply not
> implemented?)
It's not implemented. There was a patch [1] recently to implement this.
[1] https://lore.kernel.org/lkml/20200721073203.107862-1-liwei213@huawei.com/
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Justin He <Justin.He@arm.com>,
Dan Williams <dan.j.williams@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Steve Capper <Steve.Capper@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Logan Gunthorpe <logang@deltatee.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Dave Hansen <dave.hansen@linux.intel.com>,
Kees Cook <keescook@chromium.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Wei Yang <richardw.yang@linux.intel.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Ira Weiny <ira.weiny@intel.com>, Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
Date: Wed, 29 Jul 2020 17:12:54 +0300 [thread overview]
Message-ID: <20200729141254.GE3672596@linux.ibm.com> (raw)
In-Reply-To: <170d7861-4df8-ecaf-dbdd-9e9a4a832f8f@redhat.com>
On Wed, Jul 29, 2020 at 03:03:04PM +0200, David Hildenbrand wrote:
> On 29.07.20 15:00, Mike Rapoport wrote:
> > On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote:
> >>>
> >>> There is still large gap with ARM64_64K_PAGES, though.
> >>>
> >>> As for SPARSEMEM without VMEMMAP, are there actual benefits to use it?
> >>
> >> I was asking myself the same question a while ago and didn't really find
> >> a compelling one.
> >
> > Memory overhead for VMEMMAP is larger, especially for arm64 that knows
> > how to free empty parts of the memory map with "classic" SPARSEMEM.
>
> You mean the hole punching within section memmap? (which is why their
> pfn_valid() implementation is special)
Yes, arm (both 32 and 64) do this. And for smaller systems with a few
memory banks this is very reasonable to trade slight (if any) slowdown
in pfn_valid() for several megs of memory.
> (I do wonder why that shouldn't work with VMEMMAP, or is it simply not
> implemented?)
It's not implemented. There was a patch [1] recently to implement this.
[1] https://lore.kernel.org/lkml/20200721073203.107862-1-liwei213@huawei.com/
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Justin He <Justin.He@arm.com>,
Dan Williams <dan.j.williams@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Steve Capper <Steve.Capper@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Logan Gunthorpe <logang@deltatee.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Dave Hansen <dave.hansen@linux.intel.com>,
Kees Cook <keescook@chromium.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Wei Yang <richardw.yang@linux.intel.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Ira Weiny <ira.weiny@intel.com>, Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
Date: Wed, 29 Jul 2020 17:12:54 +0300 [thread overview]
Message-ID: <20200729141254.GE3672596@linux.ibm.com> (raw)
In-Reply-To: <170d7861-4df8-ecaf-dbdd-9e9a4a832f8f@redhat.com>
On Wed, Jul 29, 2020 at 03:03:04PM +0200, David Hildenbrand wrote:
> On 29.07.20 15:00, Mike Rapoport wrote:
> > On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote:
> >>>
> >>> There is still large gap with ARM64_64K_PAGES, though.
> >>>
> >>> As for SPARSEMEM without VMEMMAP, are there actual benefits to use it?
> >>
> >> I was asking myself the same question a while ago and didn't really find
> >> a compelling one.
> >
> > Memory overhead for VMEMMAP is larger, especially for arm64 that knows
> > how to free empty parts of the memory map with "classic" SPARSEMEM.
>
> You mean the hole punching within section memmap? (which is why their
> pfn_valid() implementation is special)
Yes, arm (both 32 and 64) do this. And for smaller systems with a few
memory banks this is very reasonable to trade slight (if any) slowdown
in pfn_valid() for several megs of memory.
> (I do wonder why that shouldn't work with VMEMMAP, or is it simply not
> implemented?)
It's not implemented. There was a patch [1] recently to implement this.
[1] https://lore.kernel.org/lkml/20200721073203.107862-1-liwei213@huawei.com/
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>, Kaly Xin <Kaly.Xin@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Will Deacon <will@kernel.org>, Justin He <Justin.He@arm.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Kees Cook <keescook@chromium.org>,
Ira Weiny <ira.weiny@intel.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Dave Jiang <dave.jiang@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Steve Capper <Steve.Capper@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Wei Yang <richardw.yang@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Logan Gunthorpe <logang@deltatee.com>
Subject: Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
Date: Wed, 29 Jul 2020 17:12:54 +0300 [thread overview]
Message-ID: <20200729141254.GE3672596@linux.ibm.com> (raw)
In-Reply-To: <170d7861-4df8-ecaf-dbdd-9e9a4a832f8f@redhat.com>
On Wed, Jul 29, 2020 at 03:03:04PM +0200, David Hildenbrand wrote:
> On 29.07.20 15:00, Mike Rapoport wrote:
> > On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote:
> >>>
> >>> There is still large gap with ARM64_64K_PAGES, though.
> >>>
> >>> As for SPARSEMEM without VMEMMAP, are there actual benefits to use it?
> >>
> >> I was asking myself the same question a while ago and didn't really find
> >> a compelling one.
> >
> > Memory overhead for VMEMMAP is larger, especially for arm64 that knows
> > how to free empty parts of the memory map with "classic" SPARSEMEM.
>
> You mean the hole punching within section memmap? (which is why their
> pfn_valid() implementation is special)
Yes, arm (both 32 and 64) do this. And for smaller systems with a few
memory banks this is very reasonable to trade slight (if any) slowdown
in pfn_valid() for several megs of memory.
> (I do wonder why that shouldn't work with VMEMMAP, or is it simply not
> implemented?)
It's not implemented. There was a patch [1] recently to implement this.
[1] https://lore.kernel.org/lkml/20200721073203.107862-1-liwei213@huawei.com/
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-29 14:13 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 3:34 [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` [RFC PATCH 1/6] mm/memory_hotplug: remove redundant memory block size alignment check Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` [RFC PATCH 2/6] resource: export find_next_iomem_res() helper Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` [RFC PATCH 3/6] mm/memory_hotplug: allow pmem kmem not to align with memory_block_size Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` [RFC PATCH 4/6] mm/page_alloc: adjust the start,end in dax pmem kmem case Jia He
2020-07-29 3:34 ` [RFC PATCH 4/6] mm/page_alloc: adjust the start, end " Jia He
2020-07-29 3:34 ` [RFC PATCH 4/6] mm/page_alloc: adjust the start,end " Jia He
2020-07-29 3:34 ` [RFC PATCH 5/6] device-dax: relax the memblock size alignment for kmem_start Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` [RFC PATCH 6/6] arm64: fall back to vmemmap_populate_basepages if not aligned with PMD_SIZE Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 3:34 ` Jia He
2020-07-29 6:36 ` [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment David Hildenbrand
2020-07-29 6:36 ` David Hildenbrand
2020-07-29 6:36 ` David Hildenbrand
2020-07-29 8:27 ` Justin He
2020-07-29 8:27 ` Justin He
2020-07-29 8:27 ` Justin He
2020-07-29 8:27 ` Justin He
2020-07-29 8:44 ` David Hildenbrand
2020-07-29 8:44 ` David Hildenbrand
2020-07-29 8:44 ` David Hildenbrand
2020-07-29 8:44 ` David Hildenbrand
2020-07-29 9:31 ` Mike Rapoport
2020-07-29 9:31 ` Mike Rapoport
2020-07-29 9:31 ` Mike Rapoport
2020-07-29 9:31 ` Mike Rapoport
2020-07-29 9:35 ` David Hildenbrand
2020-07-29 9:35 ` David Hildenbrand
2020-07-29 9:35 ` David Hildenbrand
2020-07-29 9:35 ` David Hildenbrand
2020-07-29 13:00 ` Mike Rapoport
2020-07-29 13:00 ` Mike Rapoport
2020-07-29 13:00 ` Mike Rapoport
2020-07-29 13:00 ` Mike Rapoport
2020-07-29 13:03 ` David Hildenbrand
2020-07-29 13:03 ` David Hildenbrand
2020-07-29 13:03 ` David Hildenbrand
2020-07-29 13:03 ` David Hildenbrand
2020-07-29 14:12 ` Mike Rapoport [this message]
2020-07-29 14:12 ` Mike Rapoport
2020-07-29 14:12 ` Mike Rapoport
2020-07-29 14:12 ` Mike Rapoport
2020-07-30 2:17 ` Justin He
2020-07-30 2:17 ` Justin He
2020-07-30 2:17 ` Justin He
2020-07-30 2:17 ` Justin 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=20200729141254.GE3672596@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=Anshuman.Khandual@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Justin.He@arm.com \
--cc=Kaly.Xin@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Steve.Capper@arm.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hsinyi@chromium.org \
--cc=jgg@ziepe.ca \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=pankaj.gupta.linux@gmail.com \
--cc=rafael@kernel.org \
--cc=will@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.