* [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice
@ 2022-09-08 3:55 Liu Shixin
2022-09-08 12:31 ` Kirill A. Shutemov
0 siblings, 1 reply; 5+ messages in thread
From: Liu Shixin @ 2022-09-08 3:55 UTC (permalink / raw)
To: Andrew Morton, Kirill A . Shutemov, Andrea Arcangeli
Cc: linux-mm, linux-kernel, Liu Shixin, Kefeng Wang
If two or more threads call get_huge_zero_page concurrently,
THP_ZERO_PAGE_ALLOC may increased two or more times. But actually,
this should only count as once since the extra zero pages has been
freed. Redefine its meaning to indicate the times a huge zero page
used for thp is successfully allocated.
Update Documentation/admin-guide/mm/transhuge.rst together.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
---
v1->v2: Update documnet.
Documentation/admin-guide/mm/transhuge.rst | 7 +++----
mm/huge_memory.c | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index c9c37f16eef8..8e3418ec4503 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -366,10 +366,9 @@ thp_split_pmd
page table entry.
thp_zero_page_alloc
- is incremented every time a huge zero page is
- successfully allocated. It includes allocations which where
- dropped due race with other allocation. Note, it doesn't count
- every map of the huge zero page, only its allocation.
+ is incremented every time a huge zero page used for thp is
+ successfully allocated. Note, it doesn't count every map of
+ the huge zero page, only its allocation.
thp_zero_page_alloc_failed
is incremented if kernel fails to allocate
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 88d98241a635..5c83a424803a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -163,7 +163,6 @@ static bool get_huge_zero_page(void)
count_vm_event(THP_ZERO_PAGE_ALLOC_FAILED);
return false;
}
- count_vm_event(THP_ZERO_PAGE_ALLOC);
preempt_disable();
if (cmpxchg(&huge_zero_page, NULL, zero_page)) {
preempt_enable();
@@ -175,6 +174,7 @@ static bool get_huge_zero_page(void)
/* We take additional reference here. It will be put back by shrinker */
atomic_set(&huge_zero_refcount, 2);
preempt_enable();
+ count_vm_event(THP_ZERO_PAGE_ALLOC);
return true;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice
2022-09-08 3:55 [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice Liu Shixin
@ 2022-09-08 12:31 ` Kirill A. Shutemov
2022-09-08 13:07 ` Liu Shixin
0 siblings, 1 reply; 5+ messages in thread
From: Kirill A. Shutemov @ 2022-09-08 12:31 UTC (permalink / raw)
To: Liu Shixin
Cc: Andrew Morton, Kirill A . Shutemov, Andrea Arcangeli, linux-mm,
linux-kernel, Kefeng Wang
On Thu, Sep 08, 2022 at 11:55:33AM +0800, Liu Shixin wrote:
> If two or more threads call get_huge_zero_page concurrently,
> THP_ZERO_PAGE_ALLOC may increased two or more times. But actually,
> this should only count as once since the extra zero pages has been
> freed. Redefine its meaning to indicate the times a huge zero page
> used for thp is successfully allocated.
I don't particularly care, but it is not obvoius why the new behaviour is
better.
All huge zero pages are freed apart from possibly the last one allocated.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice
2022-09-08 12:31 ` Kirill A. Shutemov
@ 2022-09-08 13:07 ` Liu Shixin
2022-09-08 13:25 ` Kirill A. Shutemov
0 siblings, 1 reply; 5+ messages in thread
From: Liu Shixin @ 2022-09-08 13:07 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Andrew Morton, Kirill A . Shutemov, Andrea Arcangeli, linux-mm,
linux-kernel, Kefeng Wang
On 2022/9/8 20:31, Kirill A. Shutemov wrote:
> On Thu, Sep 08, 2022 at 11:55:33AM +0800, Liu Shixin wrote:
>> If two or more threads call get_huge_zero_page concurrently,
>> THP_ZERO_PAGE_ALLOC may increased two or more times. But actually,
>> this should only count as once since the extra zero pages has been
>> freed. Redefine its meaning to indicate the times a huge zero page
>> used for thp is successfully allocated.
> I don't particularly care, but it is not obvoius why the new behaviour is
> better.
The user who read the value may be more concerned about the huge zero pages that are
really allocated using for thp and can indicated the times of calling huge_zero_page_shrinker.
I misunderstood when I first saw it.
>
> All huge zero pages are freed apart from possibly the last one allocated.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice
2022-09-08 13:07 ` Liu Shixin
@ 2022-09-08 13:25 ` Kirill A. Shutemov
2022-09-09 1:46 ` Liu Shixin
0 siblings, 1 reply; 5+ messages in thread
From: Kirill A. Shutemov @ 2022-09-08 13:25 UTC (permalink / raw)
To: Liu Shixin
Cc: Andrew Morton, Kirill A . Shutemov, Andrea Arcangeli, linux-mm,
linux-kernel, Kefeng Wang
On Thu, Sep 08, 2022 at 09:07:04PM +0800, Liu Shixin wrote:
>
>
> On 2022/9/8 20:31, Kirill A. Shutemov wrote:
> > On Thu, Sep 08, 2022 at 11:55:33AM +0800, Liu Shixin wrote:
> >> If two or more threads call get_huge_zero_page concurrently,
> >> THP_ZERO_PAGE_ALLOC may increased two or more times. But actually,
> >> this should only count as once since the extra zero pages has been
> >> freed. Redefine its meaning to indicate the times a huge zero page
> >> used for thp is successfully allocated.
> > I don't particularly care, but it is not obvoius why the new behaviour is
> > better.
> The user who read the value may be more concerned about the huge zero
> pages that are really allocated using for thp and can indicated the
> times of calling huge_zero_page_shrinker.
> I misunderstood when I first saw it.
Please, explain the motivation in the commit message.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice
2022-09-08 13:25 ` Kirill A. Shutemov
@ 2022-09-09 1:46 ` Liu Shixin
0 siblings, 0 replies; 5+ messages in thread
From: Liu Shixin @ 2022-09-09 1:46 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Andrew Morton, Kirill A . Shutemov, Andrea Arcangeli, linux-mm,
linux-kernel, Kefeng Wang
On 2022/9/8 21:25, Kirill A. Shutemov wrote:
> On Thu, Sep 08, 2022 at 09:07:04PM +0800, Liu Shixin wrote:
>>
>> On 2022/9/8 20:31, Kirill A. Shutemov wrote:
>>> On Thu, Sep 08, 2022 at 11:55:33AM +0800, Liu Shixin wrote:
>>>> If two or more threads call get_huge_zero_page concurrently,
>>>> THP_ZERO_PAGE_ALLOC may increased two or more times. But actually,
>>>> this should only count as once since the extra zero pages has been
>>>> freed. Redefine its meaning to indicate the times a huge zero page
>>>> used for thp is successfully allocated.
>>> I don't particularly care, but it is not obvoius why the new behaviour is
>>> better.
>> The user who read the value may be more concerned about the huge zero
>> pages that are really allocated using for thp and can indicated the
>> times of calling huge_zero_page_shrinker.
>> I misunderstood when I first saw it.
> Please, explain the motivation in the commit message.
Thanks, I add the motivation.
https://lore.kernel.org/all/20220909021653.3371879-1-liushixin2@huawei.com/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-09-09 1:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-08 3:55 [PATCH v2] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice Liu Shixin
2022-09-08 12:31 ` Kirill A. Shutemov
2022-09-08 13:07 ` Liu Shixin
2022-09-08 13:25 ` Kirill A. Shutemov
2022-09-09 1:46 ` Liu Shixin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).