On 18.08.20 13:00, Oscar Salvador wrote:
> Recently a customer of ours experienced a crash when booting the
> system while enabling memory-hotplug.
>
> The problem is that Normal zones on different nodes don't get their private
> zone->pageset allocated, and keep sharing the initial boot_pageset.
On 19.08.20 09:55, Anshuman Khandual wrote:
>
>
> On 08/19/2020 11:17 AM, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to sync in cmpxchg with 7 or 15
On 19.08.20 10:09, Alex Shi wrote:
>
>
> 在 2020/8/19 下午3:57, Anshuman Khandual 写道:
>>
>>
>> On 08/19/2020 11:17 AM, Alex Shi wrote:
>>> Current pageblock_flags is only 4 bits, so it has to share a char size
>>> in cmpxchg when get set, the false sharing cause perf drop.
>>>
>>> If we incrase the
There is only a single user, offline_pages(). Let's inline, to make
it look more similar to online_pages().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 16 +-
He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Cc: Charan Teja Reddy
Signed-off-by: David Hildenbrand
---
mm/Kconfig | 2 +-
mm/memory_hotplug.c | 32 ++--
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 6c974888f8
restriction now. Current users
(core and powernv/memtrace) respect these restrictions.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 10 ++
1 file changed, 10 insertions
nghua Yu
Cc: Logan Gunthorpe
Cc: Dan Williams
Cc: Mike Rapoport
Cc: "Matthew Wilcox (Oracle)"
Cc: Michel Lespinasse
Cc: linux-i...@vger.kernel.org
Signed-off-by: David Hildenbrand
---
arch/ia64/mm/init.c| 4 ++--
include/linux/memory_hotplug.h | 3 ++-
inc
Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
include/linux/memory_hotplug.h | 4 ++--
mm/page_alloc.c| 27 ---
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/include/linux/memory_hotplug.h b
pageblocks from nr_pages.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm
-by: David Hildenbrand
---
mm/memory_hotplug.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 6856702af68d9..f64478349148d 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1384,17 +1384,6
e
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 38 ++
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0011a1115381c..3aba0d956f9b1 100644
---
c: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Cc: Mel Gorman
Signed-off-by: David Hildenbrand
---
mm/page_alloc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 848664352dfe2..5db0b
Callers no longer need the number of isolated pageblocks. Let's
simplify.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 2 +-
mm/page_isolation.
: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f64478349148d..50aa5df696e9d
done,
the pageblocks are set to MIGRATE_MOVABLE, such that allocations are
possible.
I played with DIMMs and virtio-mem on x86-64 and didn't spot any surprises.
I verified that the numer of isolated pageblocks is correctly handled when
onlining/offlining.
David Hildenbrand (11):
mm/memory_
On 18.08.20 16:15, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> This is an implementation of "secret" mappings backed by a file descriptor.
>
> v4 changes:
> * rebase on v5.9-rc1
> * Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
> * Make secret mappings exclusive by defau
On 18.08.20 16:15, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Taking pages out from the direct map and bringing them back may create
> undesired fragmentation and usage of the smaller pages in the direct
> mapping of the physical memory.
>
> This can be avoided if a significantly large area
On 19.08.20 13:42, Mike Rapoport wrote:
> On Wed, Aug 19, 2020 at 12:47:54PM +0200, David Hildenbrand wrote:
>> On 18.08.20 16:15, Mike Rapoport wrote:
>>> From: Mike Rapoport
>>>
>>> Hi,
>>>
>>> This is an implementation of "secret
On 19.08.20 13:53, Mike Rapoport wrote:
> On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
>> On 18.08.20 16:15, Mike Rapoport wrote:
>>> From: Mike Rapoport
>>>
>>> Taking pages out from the direct map and bringing them back may create
>
On 19.08.20 14:37, Michal Hocko wrote:
> On Wed 19-08-20 12:11:48, David Hildenbrand wrote:
>> Already two people (including me) tried to offline subsections, because
>> the function looks like it can deal with it. But we really can only
>> online/offline full sections (e.g.,
On 19.08.20 14:40, Michal Hocko wrote:
> On Wed 19-08-20 12:11:50, David Hildenbrand wrote:
>> We make sure that we cannot have any memory holes right at the beginning
>> of offline_pages(). We no longer need walk_system_ram_range() and can
>> call __offline_isol
On 19.08.20 15:16, Michal Hocko wrote:
> On Wed 19-08-20 12:11:57, David Hildenbrand wrote:
>> Currently, it can happen that pages are allocated (and freed) via the buddy
>> before we finished basic memory onlining.
>>
>> For example, pages are exposed to the buddy
On 19.08.20 19:33, Mike Rapoport wrote:
> On Wed, Aug 19, 2020 at 02:10:43PM +0200, David Hildenbrand wrote:
>> On 19.08.20 13:53, Mike Rapoport wrote:
>>> On Wed, Aug 19, 2020 at 12:49:05PM +0200, David Hildenbrand wrote:
>>>> On 18.08.20 16:15, Mike Rapoport wr
to document the restriction now. Current users
(core and powernv/memtrace) respect these restrictions.
Acked-by: Michal Hocko
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 10
There is only a single user, offline_pages(). Let's inline, to make
it look more similar to online_pages().
Acked-by: Michal Hocko
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotp
isolated in offline_pages()", resulting in "mm/memory_hotplug: simplify page
offlining"
- Added ACKs
David Hildenbrand (10):
mm/memory_hotplug: inline __offline_pages() into offline_pages()
mm/memory_hotplug: enforce section granularity when onlining/offlining
mm/memory_
: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
include/linux/memory_hotplug.h | 4 ++--
mm/page_alloc.c| 27 ---
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/include
pageblocks from nr_pages.
Acked-by: Michal Hocko
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm
Callers no longer need the number of isolated pageblocks. Let's
simplify.
Acked-by: Michal Hocko
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c
: Michal Hocko
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 46 ++---
1 file changed, 10 insertions(+), 36 deletions(-)
diff --git a/mm
Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 38 ++
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0011a1115381c..3aba0d95
vador
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Logan Gunthorpe
Cc: Dan Williams
Cc: Mike Rapoport
Cc: "Matthew Wilcox (Oracle)"
Cc: Michel Lespinasse
Cc: linux-i...@vger.kernel.org
Signed-off-by: David Hildenbrand
---
arch/ia64/mm/init.c| 4 ++--
include/linux/memory
cko
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Cc: Mel Gorman
Signed-off-by: David Hildenbrand
---
mm/page_alloc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/mm/page_alloc.c b/mm/pag
Cc: Wei Yang
Cc: Baoquan He
Cc: Pankaj Gupta
Cc: Oscar Salvador
Cc: Charan Teja Reddy
Signed-off-by: David Hildenbrand
---
mm/Kconfig | 2 +-
mm/memory_hotplug.c | 32 ++--
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/mm/Kconfig b
On 11.01.21 05:17, Anshuman Khandual wrote:
>
>
> On 1/8/21 9:00 PM, David Hildenbrand wrote:
>>> To summarize, the section size bits for each base page size config
>>> should always
>>>
>>> a. Avoid (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_
On 04.01.21 07:18, Anshuman Khandual wrote:
>
> On 12/22/20 2:41 PM, David Hildenbrand wrote:
>> On 22.12.20 08:12, Anshuman Khandual wrote:
>>> pfn_valid() validates a pfn but basically it checks for a valid struct page
>>> backing for that pfn. It should always ret
) check that would ensure that memhp_range_allowed() has already
> been called on the hotplug path.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: David Hildenbrand
> Cc: linux-s...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Heiko Carstens
otplug/
Everywhere in this patch: Use "true/false" for boolean values.
> Cc: David Hildenbrand
> Cc: Andrew Morton
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Suggested-by: David Hildenbrand
> Signed-off-by: Anshuman Khandual
: Jonathan Cameron
Cc: h...@linux.ibm.com
Cc: Vasily Gorbik
Cc: Will Deacon
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: Heiko Carstens
Cc: Michal Hocko
Signed-off-by: David Hildenbrand
---
This is an example how virito-mem intends to use an interface like
memhp_get_pluggable_range() once around. See
e);
> VM_BUG_ON_PAGE(!PageMovable(page), page);
> /*
>* Clear registered address_space val with keeping PAGE_MAPPING_MOVABLE
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 17.12.20 14:07, Oscar Salvador wrote:
> In order to use self-hosted memmap array, the platform needs to have
> support for CONFIG_SPARSEMEM_VMEMMAP and altmap.
> Currently, only arm64, PPC and x86_64 have the support, so enable those
> platforms with ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE.
"In the fi
result = __add_memory(node, info->start_addr, info->length,
> - MHP_NONE);
> + mhp_flags);
>
> /*
>* If the memory block has been used by the kernel, add_memory()
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 17.12.20 14:07, Oscar Salvador wrote:
> Let the caller check whether it can pass MHP_MEMMAP_ON_MEMORY by
> checking mhp_supports_memmap_on_memory().
> MHP_MEMMAP_ON_MEMORY can only be set in case
> ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE is enabled, the architecture supports
> altmap, and the range to
On 11.01.21 17:33, Wesley Zhao wrote:
> From: "Wesley.Zhao"
>
> For now "reserve=" is limitied to 32bit,not available on 64bit
> platform,so we change the get_option() to get_option_ull(added in
> patch: commit 4b6bfe96265e ("lib/cmdline: add new function
> get_option_ull()"))
Curious, what's th
On 12.01.21 10:18, Dan Williams wrote:
> On Thu, Jan 7, 2021 at 1:16 AM David Hildenbrand wrote:
>>
>> [...]
>>
>>>>> Well, I would love to have no surprises either. So far there was not
>>>>> actual argument why the pmem reserved space cannot be
On 12.01.21 10:34, Dan Williams wrote:
> pfn_to_online_page() is already too large to be a macro or an inline
> function. In anticipation of further logic changes / growth, move it out
> of line.
>
> No functional change, just code movement.
>
> Cc: David Hildenbrand
> R
sing
> pfn_valid_within(), just use pfn_section_valid(). This loses the
> valid_section() check that pfn_valid_within() was performing, but that
> was already redundant with the online check.
>
> Fixes: b13bc35193d9 ("mm/hotplug: invalid PFNs from pfn_to_online_page()&quo
ase is rare, and for simplicity, the
> SECTION_TAINT_ZONE_DEVICE flag is never cleared once set.
>
> Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug")
> Cc: Andrew Morton
> Reported-by: Michal Hocko
> Reported-by: David Hildenbrand
> Signed-off-by: D
On 12.01.21 04:51, Anshuman Khandual wrote:
>
>
> On 1/11/21 7:13 PM, Oscar Salvador wrote:
>> On Mon, Jan 11, 2021 at 11:51:47AM +0100, David Hildenbrand wrote:
>>> AFAIKs, all memhp_get_pluggable_range() users pass "1".
>>>
>>> What about the
On 12.01.21 08:26, Oscar Salvador wrote:
> On Mon, Jan 11, 2021 at 05:52:19PM +0100, David Hildenbrand wrote:
>> On 17.12.20 14:07, Oscar Salvador wrote:
>>> In order to use self-hosted memmap array, the platform needs to have
>>> support for CONFIG_SPARSEMEM_VMEMMA
;
> !pfn_to_online_page() pfn the kernel hangs at dax-device shutdown due to
> a leaked reference.
>
> Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn")
> Cc: Andrew Morton
> Cc: Naoya Horiguchi
> Cc: David Hildenbrand
> Cc: Michal Hocko
&
On 11.01.21 22:01, Mike Kravetz wrote:
> While discussing a series of hugetlb fixes in [1], it became evident
> that the hugetlb specific page state information is stored in a somewhat
> haphazard manner. Code dealing with state information would be easier
> to read, understand and maintain if thi
On 10.01.21 13:40, Muchun Song wrote:
> If the refcount is one when it is migrated, it means that the page
> was freed from under us. So we are done and do not need to migrate.
>
> This optimization is consistent with the regular pages, just like
> unmap_and_move() does.
>
> Signed-off-by: Muchun
On 12.01.21 12:00, David Hildenbrand wrote:
> On 10.01.21 13:40, Muchun Song wrote:
>> If the refcount is one when it is migrated, it means that the page
>> was freed from under us. So we are done and do not need to migrate.
>>
>> This optimization is consistent with t
On 12.01.21 12:17, Oscar Salvador wrote:
> On Tue, Jan 12, 2021 at 11:12:30AM +0100, David Hildenbrand wrote:
>> On 12.01.21 08:26, Oscar Salvador wrote:
>>> You mean introducing only mm/Kconfig change in this patch, and then
>>> arch/*/Kconfig changes in separate patch
On 12.01.21 12:27, Michal Hocko wrote:
> On Tue 12-01-21 12:11:21, David Hildenbrand wrote:
>> On 12.01.21 12:00, David Hildenbrand wrote:
>>> On 10.01.21 13:40, Muchun Song wrote:
>>>> If the refcount is one when it is migrated, it means that the page
>>>&g
> Am 11.12.2020 um 10:35 schrieb Oscar Salvador :
>
> On Thu, Dec 10, 2020 at 11:55:20AM +0800, Muchun Song wrote:
>> When we free a HugeTLB page to the buddy allocator, we should allocate the
>> vmemmap pages associated with it. We can do that in the __free_hugepage()
> "vmemmap pages that des
> Am 11.12.2020 um 22:09 schrieb Pavel Tatashin :
>
> On Fri, Dec 11, 2020 at 3:46 PM Jason Gunthorpe wrote:
>>
>>> On Fri, Dec 11, 2020 at 03:40:57PM -0500, Pavel Tatashin wrote:
>>> On Fri, Dec 11, 2020 at 3:23 PM Jason Gunthorpe wrote:
On Fri, Dec 11, 2020 at 03:21:39PM -0500,
> Am 11.12.2020 um 22:36 schrieb Pavel Tatashin :
>
> On Fri, Dec 11, 2020 at 4:29 PM David Hildenbrand wrote:
>>
>>
>>>> Am 11.12.2020 um 22:09 schrieb Pavel Tatashin :
>>>
>>> On Fri, Dec 11, 2020 at 3:46 PM Jason Gunthorpe wrote:
&
> Am 12.12.2020 um 00:50 schrieb Jason Gunthorpe :
>
> On Fri, Dec 11, 2020 at 10:53:00PM +0100, David Hildenbrand wrote:
>
>>> When check_and_migrate_movable_pages() is called, the pages are
>>> already pinned. If some of those pages are in movable zone, and we
On 22.12.20 08:48, Liang Li wrote:
> Free page reporting only supports buddy pages, it can't report the
> free pages reserved for hugetlbfs case. On the other hand, hugetlbfs
The virtio-balloon free page reporting interface accepts a generic sg,
so it isn't glue to buddy pages. There is no need fo
On 22.12.20 08:49, Liang Li wrote:
> This patch add support of pre zero out free hugepage, we can use
> this feature to speed up page population and page fault handing.
>
> Cc: Alexander Duyck
> Cc: Mel Gorman
> Cc: Andrea Arcangeli
> Cc: Dan Williams
> Cc:
On 21.12.20 17:25, Liang Li wrote:
> The first version can be found at: https://lkml.org/lkml/2020/4/12/42
>
> Zero out the page content usually happens when allocating pages with
> the flag of __GFP_ZERO, this is a time consuming operation, it makes
> the population of a large vma area very slowl
On 22.12.20 09:31, David Hildenbrand wrote:
> On 22.12.20 08:49, Liang Li wrote:
>> This patch add support of pre zero out free hugepage, we can use
>> this feature to speed up page population and page fault handing.
>>
>> Cc: Alexander Duyck
>> Cc: Mel Gorman
&g
On 22.12.20 08:12, Anshuman Khandual wrote:
> pfn_valid() validates a pfn but basically it checks for a valid struct page
> backing for that pfn. It should always return positive for memory ranges
> backed with struct page mapping. But currently pfn_valid() fails for all
> ZONE_DEVICE based memory
>
>>>
>>> Virtulization
>>> =
>>> Speed up VM creation and shorten guest boot time, especially for PCI
>>> SR-IOV device passthrough scenario. Compared with some of the para
>>> vitalization solutions, it is easy to deploy because it’s transparent
>>> to guest and can handle DMA proper
[...]
>> I was rather saying that for security it's of little use IMHO.
>> Application/VM start up time might be improved by using huge pages (and
>> pre-zeroing these). Free page reporting might be improved by using
>> MADV_FREE instead of MADV_DONTNEED in the hypervisor.
>>
>>> this feature, abo
On 07.12.20 05:38, Anshuman Khandual wrote:
>
>
> On 12/3/20 5:31 PM, David Hildenbrand wrote:
>> On 03.12.20 12:51, Heiko Carstens wrote:
>>> On Thu, Dec 03, 2020 at 06:03:00AM +0530, Anshuman Khandual wrote:
>>>>>> diff --git a/arch/s390/mm/ext
On 07.12.20 10:16, Elias Carter wrote:
> I just compiled and installed 5.10 RC 7 and got a message from grub2:
> "out of memory, press any key to continue" shortly followed by a
> kernel panic (see attached screenshot).
>
> The 5.4.0-56-generic kernel from Ubuntu works on my machine fine.
>
> Thi
mal pageblock. Without this, pageblock
> @@ -1062,7 +1062,7 @@ static inline void __free_one_page(struct page *page,
> is_migrate_isolate(buddy_mt)))
> goto done_merging;
> }
> - max_order++;
> + max_order = order + 1;
> goto continue_merging;
> }
>
>
LGTM
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 07.12.20 12:30, yulei.ker...@gmail.com wrote:
> From: Yulei Zhang
>
> In current system each physical memory page is assocaited with
> a page structure which is used to track the usage of this page.
> But due to the memory usage rapidly growing in cloud environment,
> we find the resource cons
+++
> mm/memory_hotplug.c| 91 +-
> 6 files changed, 129 insertions(+), 113 deletions(-)
> create mode 100644 include/linux/bootmem_info.h
> create mode 100644 mm/bootmem_info.c
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 30.11.20 16:18, Muchun Song wrote:
> In the later patch, we will use {get,put}_page_bootmem() to initialize
> the page for vmemmap or free vmemmap page to buddy. So move them out of
> CONFIG_MEMORY_HOTPLUG_SPARSE. This is just code movement without any
> functional change.
>
> Signed-off-by: Mu
On 30.11.20 16:18, Muchun Song wrote:
> The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure
> whether to enable the feature of freeing unused vmemmap associated
> with HugeTLB pages. And this is just for dependency check. Now only
> support x86.
x86 - i386 and x86-64? (I assume th
On 30.11.20 16:18, Muchun Song wrote:
> Every HugeTLB has more than one struct page structure. The 2M HugeTLB
> has 512 struct page structure and 1G HugeTLB has 4096 struct page
> structures. We __know__ that we only use the first 4(HUGETLB_CGROUP_MIN_ORDER)
> struct page structures to store metada
On 30.11.20 16:18, Muchun Song wrote:
> In the later patch, we can use the free_vmemmap_page() to free the
> unused vmemmap pages and initialize a page for vmemmap page using
> via prepare_vmemmap_page().
>
> Signed-off-by: Muchun Song
> ---
> include/linux/bootmem_info.h | 24 ++
On 07.12.20 13:42, Muchun Song wrote:
> On Mon, Dec 7, 2020 at 8:19 PM David Hildenbrand wrote:
>>
>> On 30.11.20 16:18, Muchun Song wrote:
>>> The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure
>>> whether to enable the feature of freeing u
>>
>> Both changes only make sense with an in-tree user. I'm planning on using
>> this functionality in virtio-mem code. I can pickup your patches, drop
>> the superfluous checks, and use it from virtio-mem code. Makese sense
>> (BTW, looks like we'll see aarch64 support for virtio-mem soon)?
>
>
On 12.01.21 14:40, Muchun Song wrote:
> On Tue, Jan 12, 2021 at 7:11 PM David Hildenbrand wrote:
>>
>> On 12.01.21 12:00, David Hildenbrand wrote:
>>> On 10.01.21 13:40, Muchun Song wrote:
>>>> If the refcount is one when it is migrated, it means that the page
On 12.01.21 15:17, Muchun Song wrote:
> On Tue, Jan 12, 2021 at 9:51 PM David Hildenbrand wrote:
>>
>> On 12.01.21 14:40, Muchun Song wrote:
>>> On Tue, Jan 12, 2021 at 7:11 PM David Hildenbrand wrote:
>>>>
>>>> On 12.01.21 12:00, David Hildenb
On 12.01.21 15:23, Michal Hocko wrote:
> On Tue 12-01-21 13:16:45, Michal Hocko wrote:
> [...]
>> Well, currently pool pages are not migrateable but you are right that
>> this is likely something that we will need to look into in the future
>> and this optimization would stand in the way.
>
> Afte
g: invalid PFNs from pfn_to_online_page()")
> Cc: Qian Cai
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Reported-by: David Hildenbrand
> Signed-off-by: Dan Williams
> ---
> mm/memory_hotplug.c | 24
> 1 file changed, 20 insertions(+), 4 deleti
helper for other code paths via pgmap_pfn_valid().
>
> Other usage of get_dev_pagemap() are not a concern because those are
> operating on known data pfns having been looking up by get_user_pages().
> I.e. metadata pfns are never user mapped.
>
> Cc: Naoya Horiguchi
> Cc: Andr
On 13.01.21 02:21, Minchan Kim wrote:
> Contiguous memory allocation can be stalled due to waiting
> on page writeback and/or page lock which causes unpredictable
> delay. It's a unavoidable cost for the requestor to get *big*
> contiguous memory but it's expensive for *small* contiguous
> memory(e
On 13.01.21 04:31, Linus Torvalds wrote:
> On Tue, Jan 12, 2021 at 6:16 PM Matthew Wilcox wrote:
>>
>> The thing about the speculative page cache references is that they can
>> temporarily bump a refcount on a page which _used_ to be in the page
>> cache and has now been reallocated as some other
On 13.01.21 09:52, David Hildenbrand wrote:
> On 13.01.21 04:31, Linus Torvalds wrote:
>> On Tue, Jan 12, 2021 at 6:16 PM Matthew Wilcox wrote:
>>>
>>> The thing about the speculative page cache references is that they can
>>> temporarily bump a refcount on a
epage(hpage);
> + return MIGRATEPAGE_SUCCESS;
> + }
> +
> new_hpage = get_new_page(hpage, private);
> if (!new_hpage)
> return -ENOMEM;
>
Happy to say that I now know understand what's going on here
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 11.01.21 20:40, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The first 4Kb of memory is a BIOS owned area and to avoid its allocation
> for the kernel it was not listed in e820 tables as memory. As the result,
> pfn 0 was never recognised by the generic memory management and it is not a
> pa
R(mnt)) {
> error = PTR_ERR(mnt);
> goto out_unreg;
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
e = alloc_huge_page(&pseudo_vma, addr, 0);
> hugetlb_drop_vma_policy(&pseudo_vma);
> if (IS_ERR(page)) {
> mutex_unlock(&hugetlb_fault_mutex_table[hash]);
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 18.01.21 14:12, Anshuman Khandual wrote:
> This introduces memhp_range_allowed() which can be called in various memory
> hotplug paths to prevalidate the address range which is being added, with
> the platform. Then memhp_range_allowed() calls memhp_get_pluggable_range()
> which provides applica
a VM_BUG_ON() check that would ensure that memhp_range_allowed()
> has already been called.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ard Biesheuvel
> Cc: Mark Rutland
> Cc: David Hildenbrand
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vg
On 18.01.21 14:21, Anshuman Khandual wrote:
>
>
> On 1/18/21 6:43 PM, Anshuman Khandual wrote:
>> From: David Hildenbrand
>>
>> Right now, we only check against MAX_PHYSMEM_BITS - but turns out there
>> are more restrictions of which memory we can actually h
) check that would ensure that memhp_range_allowed() has already
> been called on the hotplug path.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: David Hildenbrand
> Cc: linux-s...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Heiko Carstens
hotplug call chain, which inevitably fails the hotplug itself.
>
> This mechanism was suggested by David Hildenbrand during another discussion
> with respect to a memory hotplug fix on arm64 platform.
>
> https://lore.kernel.org/linux-arm-kernel/1600332402-30123-1-git-send-emai
On 17.12.20 14:07, Oscar Salvador wrote:
> Physical memory hotadd has to allocate a memmap (struct page array) for
> the newly added memory section. Currently, alloc_pages_node() is used
> for those allocations.
>
> This has some disadvantages:
> a) an existing memory is consumed for that purpose
On 06.01.21 07:11, Anshuman Khandual wrote:
> Hi Sudershan,
>
> This patch (and the cover letter) does not copy LAKML even though the
> entire change here is arm64 specific. Please do copy all applicable
> mailing lists for a given patch.
>
> On 1/6/21 6:58 AM, Sudarshan Rajagopalan wrote:
>> Cur
> To summarize, the section size bits for each base page size config
> should always
>
> a. Avoid (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS
Pageblocks must also always fall completely into a section.
>
> b. Provide minimum possible section size for a given base page config to
>have i
+2084,6 @@ unsigned long __init memblock_free_all(void)
>
> pages = free_low_memory_core_early();
> totalram_pages_add(pages);
> -
> - return pages;
> }
>
> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_ARCH_KEEP_MEMBLOCK)
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 14.01.21 12:31, Miaohe Lin wrote:
> When gbl_reserve is 0, hugetlb_acct_memory() will do nothing except holding
> and releasing hugetlb_lock.
So, what's the deal then? Adding more code?
If this is a performance improvement, we should spell it out. Otherwise
I don't see a real benefit of this p
801 - 900 of 3183 matches
Mail list logo
