rent
code. The performance issues discovered here will be taken into account with
the new code. However, as previously mentioned additional synchronization
is required for functional correctness. As a result, there will be some
regression in this code.
-
On 10/9/20 3:23 PM, Hugh Dickins wrote:
> On Fri, 9 Oct 2020, Mike Kravetz wrote:
>> On 10/8/20 10:50 PM, Hugh Dickins wrote:
>>>
>>> It's a problem I've faced before in tmpfs, keeping a hold on the
>>> mapping while page lock is dropped. Quite a
On 10/8/20 10:50 PM, Hugh Dickins wrote:
> On Thu, 8 Oct 2020, Mike Kravetz wrote:
>> On 10/7/20 8:21 PM, Hugh Dickins wrote:
>>>
>>> Mike, j'accuse... your 5.7 commit c0d0381ade79 ("hugetlbfs:
>>> use i_mmap_rwsem for more pmd sharing synchronization&
t was possible to find a PageAnon there.)
>
> But my belief (best confirmed by you running your tests with a
> suitably placed BUG_ON or WARN_ON) is that you'll never find a
> PageAnon in a vma_shareable() area, so will never need try_to_unmap()
> to unshare a pagetable in
On 9/29/20 2:58 PM, Mike Kravetz wrote:
> On 9/15/20 5:59 AM, Muchun Song wrote:
>> Hi all,
>>
>> This patch series will free some vmemmap pages(struct page structures)
>> associated with each hugetlbpage when preallocated to save memory.
> ...
>> The mappin
On 10/2/20 4:25 AM, Michal Hocko wrote:
> On Wed 30-09-20 15:03:11, Mike Kravetz wrote:
>> On 9/30/20 1:47 PM, Vijay Balakrishna wrote:
>>> On 9/30/2020 11:20 AM, Mike Kravetz wrote:
>>>> On 9/29/20 9:49 AM, Vijay Balakrishna wrote:
>>>>
>>>> S
migration statistics. While here, this updates current trace event
> 'mm_migrate_pages' to accommodate now available HugeTLB based statistics.
>
> Cc: Daniel Jordan
> Cc: Zi Yan
> Cc: John Hubbard
> Cc: Mike Kravetz
> Cc: Oscar Salvador
> Cc: Andrew Morton
>
at, but hopefully avoids some confusion.
--
Mike Kravetz
> So we introduce a new nr_free_vmemmap_pages field in the hstate to
> indicate how many vmemmap pages associated with a hugetlb page that we
> can free to buddy system.
>
> Signed-off-by: Muchun Song
> ---
> inc
On 9/30/20 1:47 PM, Vijay Balakrishna wrote:
> On 9/30/2020 11:20 AM, Mike Kravetz wrote:
>> On 9/29/20 9:49 AM, Vijay Balakrishna wrote:
>>
>> Sorry for jumping in so late. Should we use this as an opportunity to
>> also fix up the messages logged when (re)calculating
ree_kbytes is not updated to 11334 because user defined
value 9 is preferred
# cat /proc/sys/vm/min_free_kbytes
90112
--
Mike Kravetz
support it, say Y here.
> +
> + If unsure, say N.
> +
I could be wrong, but I believe the convention is introduce the config
option at the same time code which depends on the option is introduced.
Therefore, it might be better to combine with the next patch.
Also, it looks like most of your development was done on x86. Should
this option be limited to x86 only for now?
--
Mike Kravetz
On 9/15/20 5:59 AM, 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.
>
> Signed-off-by: Muchun Song
More code movement.
Acked-b
On 9/15/20 5:59 AM, Muchun Song wrote:
> Move bootmem info registration common API to individual bootmem_info.c
> for later patch use.
>
> Signed-off-by: Muchun Song
This is just code movement.
Acked-by: Mike Kravetz
--
Mike Kravetz
> ---
> arch/x86/mm/init_64.c
rt of double mapping hugetlb pages.
https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg02407.html
More care/coordination would be needed to support double mapping with
this new option. However, this series provides a boot option to disable
freeing of unneeded page structs.
--
Mike Kravetz
is_hugetlb = true;
else
is_thp = true;
Although, the compiler may be able to optimize. I did not check.
> +
> nr_subpages = thp_nr_pages(page);
> + if (is_hugetlb)
> + nr_subpages =
> pages_per_huge_page(page_hstate(page));
Can we just use compound_order() here for all cases?
--
Mike Kravetz
On 9/16/20 1:40 PM, Joe Perches wrote:
> Convert the unbound sprintf in hugetlb_report_node_meminfo to use
> sysfs_emit_at so that no possible overrun of a PAGE_SIZE buf can occur.
>
> Signed-off-by: Joe Perches
Acked-by: Mike Kravetz
--
Mike Kravetz
4002c8 RCX: 00440329
> RDX: RSI: 4000 RDI: 20001000
> RBP: 006ca018 R08: R09:
> R10: 0003 R11: 0246 R12: 00401b30
> R13: 00401bc0 R14: R15:
On 9/16/20 2:14 AM, Song Bao Hua (Barry Song) wrote:
>>> -Original Message-
>>> From: Mike Kravetz [mailto:mike.krav...@oracle.com]
>>> Sent: Wednesday, September 16, 2020 8:57 AM
>>> To: linux...@kvack.org; linux-kernel@vger.kernel.org;
>>>
On 9/15/20 9:32 PM, Christoph Hellwig wrote:
> On Wed, Sep 02, 2020 at 08:02:04PM -0700, Mike Kravetz wrote:
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -383,25 +383,34 @@ postcore_initcall(atomic_pool_init);
>> struct dma_contig_early_re
before normal memory allocators, so use the memblock
allocator.
Acked-by: Roman Gushchin
Signed-off-by: Mike Kravetz
---
rfc->v1
- Made minor changes suggested by Song Bao Hua (Barry Song)
- Removed check for late calls to cma_init_reserved_mem that was part
of RFC.
- Added ACK f
his should have been included with commit 34ae204f1851
("hugetlbfs: remove call to huge_pte_alloc without i_mmap_rwsem").
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.
On 9/3/20 6:58 PM, Song Bao Hua (Barry Song) wrote:
>
>> -Original Message-
>> From: Mike Kravetz [mailto:mike.krav...@oracle.com]
>> Sent: Thursday, September 3, 2020 3:02 PM
>> To: linux...@kvack.org; linux-kernel@vger.kernel.org;
>> linux-arm-ke
adding 1G hugetlb pages to
the hugetlb pool and then using them within applications? Or, are you
dynamically allocating them at fault time (hugetlb overcommit/surplus)?
Latency time for use of such pages includes:
- Putting together 1G contiguous
- Clearing 1G memory
In the 'allocation at fault time' mode you incur both costs at fault time.
If using pages from the pool, your only cost at fault time is clearing the
page.
--
Mike Kravetz
before normal memory allocators, so use the memblock
allocator.
Signed-off-by: Mike Kravetz
---
arch/arm/mm/dma-mapping.c | 29 ---
arch/mips/configs/cu1000-neo_defconfig | 1 -
arch/mips/configs/cu1830-neo_defconfig | 1 -
include/linux/cma.h
On 9/2/20 3:49 AM, Vlastimil Babka wrote:
> On 9/1/20 3:46 AM, Wei Yang wrote:
>> The page allocated from buddy is not on any list, so just use list_add()
>> is enough.
>>
>> Signed-off-by: Wei Yang
>> Reviewed-by: Baoquan He
>> Reviewed-by: Mike Kravet
t; Signed-off-by: Wei Yang
Thank you!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
break;
Previously, when encountering a PageHWPoison(page) the loop would continue
and check the next page in the list. It now breaks the loop and returns
NULL. Is not this a change in behavior? Perhaps you want to change that
break to a continue. Or, restructure in s
o threads running in parallel can modify table->data
in the global data structure without any synchronization. Worse yet, is
that that value is local to their stacks. That was the root cause of the
issue addressed by Muchun's patch.
Does that analysis make sense? Or, are we missing something.
--
Mike Kravetz
t; Signed-off-by: Wei Yang
> Reviewed-by: Mike Kravetz
Commit bbe88753bd42 (mm/hugetlb: make hugetlb migration callback CMA aware)
in v5.9-rc2 modified dequeue_huge_page_node_exact. This patch will need
to be updated to take those changes into account.
--
Mike Kravetz
On 8/27/20 8:32 PM, Wei Yang wrote:
> We are sure to get a valid file_region, otherwise the
> VM_BUG_ON(resv->region_cache_count <= 0) at the very beginning would be
> triggered.
>
> Let's remove the redundant one.
>
> Signed-off-by: Wei Yang
Thank you.
Revi
_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: e5ff215941d5 ("hugetlb: multiple hstates for multiple page sizes")
> Signed-off-by: Muchun Song
Thank you!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
s set when the hugetlb ctl_table
entries are defined and initialized. This is not something you introduced.
The unnecessary assignments are in the existing code. However, there is no
need to carry them forward.
--
Mike Kravetz
n Xing and improved performance by 20
something percent. That seems in line with this report/improvement.
Perhaps the tooling is not always accurate in determining the commit which
causes the performance changes?
Perhaps I am misreading information in the reports?
--
Mike Kravetz
On 8/24/20 8:01 PM, Muchun Song wrote:
> On Tue, Aug 25, 2020 at 5:21 AM Mike Kravetz wrote:
>>
>> I too am looking at this now and do not completely understand the race.
>> It could be that:
>>
>> hugetlb_sysctl_handler_common
>> ...
&
Hello Andrew,
Unless someone objects, can you add patches 1-3 of this series to your tree.
They have been reviewed and are fairly simple cleanups.
--
Mike Kravetz
On 7/22/20 8:22 PM, Baoquan He wrote:
> v1 is here:
> https://lore.kernel.org/linux-mm/20200720062623.13135-1-...@redh
Instead of
changing the code to 'handle the race', I think it might be acceptable to just
put a big semaphore around it.
--
Mike Kravetz
On 8/21/20 2:02 PM, Mike Kravetz wrote:
> Would you be willing to test this series on top of 34ae204f1851? I will need
> to rebase the series to take the changes made by 34ae204f1851 into account.
Actually, the series in this thread will apply/run cleanly on top of
34ae204f1851. No n
On 8/21/20 1:47 PM, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-
>> From: Song Bao Hua (Barry Song)
>> Sent: Saturday, August 22, 2020 7:27 AM
>> To: 'Mike Kravetz' ; h...@lst.de;
>> m.szyprow...@samsung.com; robin.mur...
On 8/21/20 1:39 AM, Xing Zhengjun wrote:
>
>
> On 6/26/2020 5:33 AM, Mike Kravetz wrote:
>> On 6/22/20 3:01 PM, Mike Kravetz wrote:
>>> On 6/21/20 5:55 PM, kernel test robot wrote:
>>>> Greeting,
>>>>
>>>> FYI, we noticed a -33.4%
asn't too worried because of
the limited hugetlb use case. However, this series is adding another user
of per-node CMA areas.
With more users, should try to sync up number of CMA areas and number of
nodes? Or, perhaps I am worrying about nothing?
--
Mike Kravetz
On 8/11/20 4:19 PM, Wei Yang wrote:
> On Tue, Aug 11, 2020 at 02:43:28PM -0700, Mike Kravetz wrote:
>> Subject: [PATCH] hugetlb: optimize race error return in
>> alloc_surplus_huge_page
>>
>> The routine alloc_surplus_huge_page() could race with with a pool
>> s
this, let's just leave things as they are and not add the message.
It is pretty clear that a user needs to read the value after writing to
determine if all pages were allocated. The log message would add little
benefit to the end user.
--
Mike Kravetz
I 'tested' it by allocating
an 'extra' page and freeing it via this method in alloc_surplus_huge_page.
>From 864c5f8ef4900c95ca3f6f2363a85f3cb25e793e Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Tue, 11 Aug 2020 12:45:41 -0700
Subject: [PATCH] hugetlb: optimize race
Cc: Michal
On 8/10/20 7:11 PM, Baoquan He wrote:
> Hi Mike,
>
> On 07/23/20 at 11:21am, Mike Kravetz wrote:
>> On 7/23/20 2:11 AM, Baoquan He wrote:
> ...
>>>> But is kernel expected to warn for all such situations where the user
>>>> requested r
o race with a pool resize which itself could cause surplus
to exceed overcommit.
IMO both approaches are valid.
- Advantage of temporary page is that it can not cause surplus to exceed
overcommit. Disadvantage is as mentioned in the comment 'abuse of temporary
page'.
- Advantage of this patch is that it uses existing counters. Disadvantage
is that it can momentarily cause surplus to exceed overcommit.
Unless someone has a strong opinion, I prefer the changes in this patch.
--
Mike Kravetz
On 8/7/20 2:12 AM, Wei Yang wrote:
> set_hugetlb_cgroup_[rsvd] just manipulate page local data, which is not
> necessary to be protected by hugetlb_lock.
>
> Let's take this out.
>
> Signed-off-by: Wei Yang
Thanks!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
t; Signed-off-by: Wei Yang
I agree with Baoquan He in that this is more of a style change. Certainly
there is the potential to avoid an extra check and that is always good.
The real value in this patch (IMO) is removal of the stale comment.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
On 8/7/20 2:12 AM, Wei Yang wrote:
> The page allocated from buddy is not on any list, so just use list_add()
> is enough.
>
> Signed-off-by: Wei Yang
Thanks!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
https://lore.kernel.org/linux-mm/e670f327-5cf9-1959-96e4-6dc7cc30d...@oracle.com/
--
Mike Kravetz
stand. I
might have:
- Removed the function parameter.
- Added local variable
bool count_only = regions_needed != NULL;
- Left remaining code as it.
I'm OK with the proposed change. Any change to readability is VERY minimal.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
s!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
gt; + nrg = list_first_entry_or_null(&resv->region_cache,
>>> + struct file_region, link);
>>> VM_BUG_ON(!nrg);
>
> Or we can remove this VM_BUG_ON()?
>
I would prefer that we just remove the 'VM_BUG_ON(!nrg)'. Code elsewhere
is responsible for making sure there is ALWAYS an entry in the cache. That
is why the 'VM_BUG_ON(resv->region_cache_count <= 0)' is at the beginning
of the routine.
--
Mike Kravetz
It is unfortunate that the region management code is difficult
to understand.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> nasty free_huge_page
>
> mm/hugetlb.c | 101 ++-
> 1 file changed, 44 insertions(+), 57 deletions(-)
Thanks Wei Yang!
I'll take a look at these next week.
--
Mike Kravetz
On 8/3/20 4:00 PM, Mike Kravetz wrote:
> On 8/3/20 3:52 PM, Matthew Wilcox wrote:
>> On Mon, Aug 03, 2020 at 03:43:35PM -0700, Mike Kravetz wrote:
>>> Commit c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
>>> synchronization") requi
On 8/3/20 3:52 PM, Matthew Wilcox wrote:
> On Mon, Aug 03, 2020 at 03:43:35PM -0700, Mike Kravetz wrote:
>> Commit c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
>> synchronization") requires callers of huge_pte_alloc to hold i_mmap_rwsem
>> in at le
ppropriate
locking.
Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
synchronization")
Cc:
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 4
1 file changed, 4 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 590111ea6975..0f6716422a53 100644
--- a/m
On 7/30/20 4:26 PM, Peter Xu wrote:
> Hi, Mike,
>
> On Thu, Jul 30, 2020 at 02:49:18PM -0700, Mike Kravetz wrote:
>> On 7/30/20 1:16 PM, Peter Xu wrote:
>>> This is found by code observation only.
>>>
>>> Firstly, the worst case scenario should assume t
is an actual problem in the existing code
that needs to be fixed in stable. I think the existing code is correct, just
inefficient.
--
Mike Kravetz
x4d/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: c64be2bb1c6e ("drivers: add Contiguous Memory Allocator")
Signed-off-by: Mike Kravetz
Cc:
---
mm/cma.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index
7;Return -EBUSY' removed from the comment and
assumed the code would not return an error code. The code now more
explicitly does return -EBUSY. My concern was when I incorrectly thought
you were removing the error return code. Sorry for the noise.
Acked-by: Mike Kravetz
--
Mike Kravetz
d unusable.
Admittedly, these races are rare and I had to work really hard to produce
them. I'll try to find my testing mechanism. My concern is reintroducing
this abandoning of pageblocks. I have not looked further in your series
to see if this potentially addressed later. If no
patch summarizes the issues.
IMO, at this time it makes little sense to perform checks for more than
MPOL_BIND at reservation time. If we ever take on the monumental task of
supporting mempolicy directed per-node reservations throughout the life of
a process, support for other policies will need to be taken into account.
--
Mike Kravetz
callq 0x81060f80 <__fentry__>
0x8126a3a5 <+5>: xor%eax,%eax
0x8126a3a7 <+7>: mov%gs:0x17bc0,%rdx
0x8126a3b0 <+16>: testb $0x1,0x778(%rdx)
0x8126a3b7 <+23>:jne0x8126a3ba
0x8126a3b9 <+25>:retq
0x8126a3ba <+26>:mov0x6c(%rdi),%eax
0x8126a3bd <+29>:retq
End of assembler dump.
--
Mike Kravetz
olicy. This new code will help
produce a quick failure as described in the commit message, and it does
not make existing interactions any worse.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
you have multiple gigantic page sizes supported at one
time (one system instance) on powerpc?
--
Mike Kravetz
goto out;
> }
There is a big comment before this code in hugetlb_acct_memory. The comment
only talks about cpusets. We should probably update that to include mempolicy
as well. It could be as simple as s/cpuset/cpuset or mempolicy/.
--
Mike Kravetz
h hugetlb usage.
I do not feel strongly one way or another about adding the warning. Since
it is fairly trivial and could help diagnose issues I am in favor of adding
it. If people feel strongly that it should not be added, I am open to
those arguments.
--
Mike Kravetz
On 7/22/20 1:49 AM, Baoquan He wrote:
> On 07/20/20 at 05:38pm, Mike Kravetz wrote:
>>> + if (count != h->max_huge_pages) {
>>> + char buf[32];
>>> +
>>> + string_get_size(huge_page_size(h), 1, STRING_UNITS_2, buf, 32);
>>> +
20:44:57 +1000
> Subject: [PATCH] mm/hugetlb: better checks before using hugetlb_cma
>
> Signed-off-by: Stephen Rothwell
Thanks Stephen, sorry for missing that in review.
Acked-by: Mike Kravetz
--
Mike Kravetz
> ---
> mm/hugetlb.c | 9 ++---
> 1 file changed, 6 insertions(
gt; old_max ? "increased" : "decreased",
> + abs(old_max - h->max_huge_pages));
> + }
> spin_unlock(&hugetlb_lock);
I would prefer if we drop the lock before logging the message. That would
involve grabbing the value of h->max_huge_pages before dropping the lock.
--
Mike Kravetz
>
> NODEMASK_FREE(node_alloc_noretry);
>
can
> optionally be followed by the hugepages parameter to preallocate a
> specific number of huge pages of default size. The number of default
>
Unfortunately, this review comment was missed when the typo was introduced.
https://lore.kernel.org/lkml/5ca27419-7496-8799
entry_migration()
> and is_hugetlb_entry_hwpoisoned() to simplify code.
>
> Signed-off-by: Baoquan He
Agreed, we can remove the checks for non_swap_entry.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> ---
> mm/hugetlb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On 7/19/20 11:26 PM, Baoquan He wrote:
> Just like his neighbour is_hugetlb_entry_migration() has done.
>
> Signed-off-by: Baoquan He
Thanks,
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> ---
> mm/hugetlb.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
&g
ma(vma);
> unsigned long reserve, start, end;
> - long gbl_reserve;
> + long glb_reserve;
I see both 'gbl' and 'glb' being used for global in variable names. grep will
actually return more hits for gbl than glb. Unless there is consensus that
'gl
On 7/19/20 11:22 PM, Anshuman Khandual wrote:
>
>
> On 07/17/2020 10:32 PM, Mike Kravetz wrote:
>> On 7/16/20 10:02 PM, Anshuman Khandual wrote:
>>>
>>>
>>> On 07/16/2020 11:55 PM, Mike Kravetz wrote:
>>>> >From 17c8f37afbf42fe7412e6eeb
On 7/17/20 2:51 AM, Anshuman Khandual wrote:
>
>
> On 07/17/2020 02:06 PM, Will Deacon wrote:
>> On Fri, Jul 17, 2020 at 10:32:53AM +0530, Anshuman Khandual wrote:
>>>
>>>
>>> On 07/16/2020 11:55 PM, Mike Kravetz wrote:
>>>> >From 17c8f37a
On 7/16/20 10:02 PM, Anshuman Khandual wrote:
>
>
> On 07/16/2020 11:55 PM, Mike Kravetz wrote:
>> >From 17c8f37afbf42fe7412e6eebb3619c6e0b7e1c3c Mon Sep 17 00:00:00 2001
>> From: Mike Kravetz
>> Date: Tue, 14 Jul 2020 15:54:46 -0700
>> Subject: [PATCH] h
> Signed-off-by: Naoya Horiguchi
> Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
--
Mike Kravetz
On 7/16/20 1:12 AM, Will Deacon wrote:
> On Wed, Jul 15, 2020 at 09:59:24AM -0700, Mike Kravetz wrote:
>>
>> So, everything in the existing code really depends on the hugetlb definition
>> of gigantic page (order >= MAX_ORDER). The code to check for
>> 'order &g
there are more use cases, or this seems too simple we can
revisit that decision.
>> +
>> parsed_hstate = h;
>> }
>>
>> @@ -5647,7 +5650,10 @@ void __init hugetlb_cma_reserve(int order)
>> unsigned long size, reserved, per_node;
>> int nid;
>>
>> -cma_reserve_called = true;
>> +if (cma_reserve_called)
>> +return;
>> +else
>> +cma_reserve_called = true;
>
> (nit: don't need the 'else' here)
Yes, duh!
--
Mike Kravetz
On 7/15/20 4:14 AM, Song Bao Hua (Barry Song) wrote:
>> From: Mike Kravetz [mailto:mike.krav...@oracle.com]
>> huge_page_size(h)/1024);
>>
>> +if (order >= MAX_ORDER && hugetlb_cma_size)
>> +hugetlb_cma
Gushchin
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: H. Peter Anvin
> Cc: Mike Kravetz
> Cc: Mike Rapoport
> Cc: Andrew Morton
> Cc: Anshuman Khandual
> Cc: Jonathan Cameron
> Signed-o
and code
>>> [-Wdeclaration-after-statement]
>>>
>>> Instead we should switch to C99 and declare it as "for (int __nr_nodes" :P
>>
>> Hmm... I tried what you suggested, but compiler complains.
>>
>> 'for' loop initial declarations are only allowed in C99 or C11 mode
>
> Yes, by "we should switch to C99" I meant that the kernel kbuild system would
> need to switch. Not a trivial change...
> Without that, I don't see how your patch is possible to do safely.
Vlastimil, thanks for pointing out future potential issues with this patch.
I likely would have missed that.
Wei, thanks for taking the time to put together the patch. However, I tend
to agree with Vlastimil's assesment. The cleanup is not worth the risk of
running into issues if someone uses multiple instances of the macro.
--
Mike Kravetz
ouble reservation and CMA leak.
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages
> using cma")
> Cc: Mike Kravetz
> Cc: Jonathan Cameron
> Acked-by: Roman Gushchin
> Signed-off-by: Barry Song
Thank you!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
On 7/9/20 4:45 PM, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-----
>> From: Mike Kravetz [mailto:mike.krav...@oracle.com]
>> Sent: Friday, July 10, 2020 6:58 AM
>> To: Song Bao Hua (Barry Song) ; Roman
>> Gushchin
>> Cc: Andrew Mo
_reserve when we reserve CMA.
--
Mike Kravetz
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index fab4485b9e52..92cb882cf287 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -46,6 +46,7 @@ unsigned int default_hstate_idx;
struct hstate hstates[HUGE_MAX_HSTATE];
static struct cma *hugetlb_cma[MAX_
age() uses memalloc_nocma_{save,restore}
> to exclude CMA memory rather than manually clearing __GFP_MOVABLE. And,
> this patch also makes the deque function on hugetlb CMA aware. In the
> deque function, CMA memory is skipped if PF_MEMALLOC_NOCMA flag is set
> by memalloc_nocma_{sa
parsing time and there would be no need for such
a check in the allocation code (except for sanity cheching).
Thoughts? I just cleaned up the parsing code and could make such a change
quite easily.
--
Mike Kravetz
necessary.
File truncation (remove_inode_hugepages) needs to handle page mapping
changes before locking the page. This could happen if page was added
to page cache and later backed out in fault processing.
Reported-by: kernel test robot
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 41
ted.
[1] https://lore.kernel.org/lkml/20200622005551.GK5535@shao2-debian
Mike Kravetz (3):
Revert: "hugetlbfs: Use i_mmap_rwsem to address page fault/truncate
race"
hugetlbfs: Only take i_mmap_rwsem when sharing is possible
huegtlbfs: handle page fault/truncate races
f
always take i_mmap_rwsem. These are not as performance
sensitive.
Reported-by: kernel test robot
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 96 ++--
1 file changed, 63 insertions(+), 33 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 28
mm/hugetlb.c | 23 ---
2 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index ef5313f9c78f..b4bb82815dd4 100644
--- a/fs
uot;
> Signed-off-by: Naoya Horiguchi
Reviewed-by: Mike Kravetz
--
Mike Kravetz
ome functions like
> hwpoison_user_mappings() and identify_page_state(), so they should properly
> handle 4kB page, thp, and hugetlb.
>
> Signed-off-by: Naoya Horiguchi
> Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
--
Mike Kravetz
n.
>>
>> As I've said I would _prefer_ simplicity over "correctness" if it is only
>> partial and hard to reason about from the userspace experience but this
>> is not something I would _insist_ on. If Mike as a maintainer of the
>> code is ok with that th
smaller than PMD_SIZE.
Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
synchronization")
Cc: sta...@kernel.org
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 57
On 6/22/20 3:01 PM, Mike Kravetz wrote:
> On 6/21/20 5:55 PM, kernel test robot wrote:
>> Greeting,
>>
>> FYI, we noticed a -33.4% regression of vm-scalability.throughput due to
>> commit:
>>
>>
>> commit: c0d0381ade79885c04a04c303284b040616b116e (
On 6/25/20 5:01 AM, Aneesh Kumar K.V wrote:
> Mike Kravetz writes:
>
>> On 6/24/20 2:26 AM, Bibo Mao wrote:
>>> When set_pmd_at is called in function do_huge_pmd_anonymous_page,
>>> new tlb entry can be added by software on MIPS platform.
>>>
>>>
itectures. arc looks like it could be
problematic as update_mmu_cache_pmd calls update_mmu_cache and then
operates on (address & PAGE_MASK). That could now be different.
--
Mike Kravetz
>
> Signed-off-by: Bibo Mao
> ---
> mm/huge_memory.c | 2 ++
> 1 file chang
401 - 500 of 1139 matches
Mail list logo
