[v2] mm/hugetlb: avoid unnecessary hugetlb_acct_memory() call

Commit Message

Miaohe Lin Jan. 15, 2021, 9:20 a.m. UTC

When gbl_reserve is 0, hugetlb_acct_memory() will do nothing except holding
and releasing hugetlb_lock. We should avoid this unnecessary hugetlb_lock
lock/unlock cycle which is happening on 'most' hugetlb munmap operations by
check delta against 0 at the beginning of hugetlb_acct_memory.

Reviewed-by: David Hildenbrand <[e-mail]>
Signed-off-by: Miaohe Lin <[e-mail]>
---
 mm/hugetlb.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Oscar Salvador Jan. 15, 2021, 9:28 a.m. UTC | #1

On Fri, Jan 15, 2021 at 04:20:13AM -0500, Miaohe Lin wrote:
> When gbl_reserve is 0, hugetlb_acct_memory() will do nothing except holding
> and releasing hugetlb_lock. We should avoid this unnecessary hugetlb_lock
> lock/unlock cycle which is happening on 'most' hugetlb munmap operations by
> check delta against 0 at the beginning of hugetlb_acct_memory.
> 
> Reviewed-by: David Hildenbrand <[e-mail]>
> Signed-off-by: Miaohe Lin <[e-mail]>

I would avoid mentioning gbl_reserve as not all callers use it, and focus
on what delta means:

"When reservation accounting remains unchanged..", but anyway:

Reviewed-by: Oscar Salvador <[e-mail]>

Miaohe Lin Jan. 15, 2021, 9:44 a.m. UTC | #2

Hi:

On 2021/1/15 17:28, Oscar Salvador wrote:
> On Fri, Jan 15, 2021 at 04:20:13AM -0500, Miaohe Lin wrote:
>> When gbl_reserve is 0, hugetlb_acct_memory() will do nothing except holding
>> and releasing hugetlb_lock. We should avoid this unnecessary hugetlb_lock
>> lock/unlock cycle which is happening on 'most' hugetlb munmap operations by
>> check delta against 0 at the beginning of hugetlb_acct_memory.
>>
>> Reviewed-by: David Hildenbrand <[e-mail]>
>> Signed-off-by: Miaohe Lin <[e-mail]>
> 
> I would avoid mentioning gbl_reserve as not all callers use it, and focus
> on what delta means:
> 
> "When reservation accounting remains unchanged..", but anyway:

Sounds good. Maybe Andrew could kindly do this if this patch is picked up ?

> 
> Reviewed-by: Oscar Salvador <[e-mail]>
> 
> 

Many thanks for your review.

Mike Kravetz Jan. 19, 2021, 5:44 p.m. UTC | #3

On 1/15/21 1:44 AM, Miaohe Lin wrote:
> Hi:
> 
> On 2021/1/15 17:28, Oscar Salvador wrote:
>> On Fri, Jan 15, 2021 at 04:20:13AM -0500, Miaohe Lin wrote:
>>> When gbl_reserve is 0, hugetlb_acct_memory() will do nothing except holding
>>> and releasing hugetlb_lock. We should avoid this unnecessary hugetlb_lock
>>> lock/unlock cycle which is happening on 'most' hugetlb munmap operations by
>>> check delta against 0 at the beginning of hugetlb_acct_memory.
>>>
>>> Reviewed-by: David Hildenbrand <[e-mail]>
>>> Signed-off-by: Miaohe Lin <[e-mail]>
>>
>> I would avoid mentioning gbl_reserve as not all callers use it, and focus
>> on what delta means:
>>
>> "When reservation accounting remains unchanged..", but anyway:
> 
> Sounds good. Maybe Andrew could kindly do this if this patch is picked up ?

Thank you and Andrew.

Looks like Andrew updated the commit message and added to his tree.

Patch

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4f67f6b159c7..da064cb8fd53 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3591,6 +3591,9 @@  static int hugetlb_acct_memory(struct hstate *h, long delta)
 {
 	int ret = -ENOMEM;
 
+	if (!delta)
+		return 0;
+
 	spin_lock(&hugetlb_lock);
 	/*
 	 * When cpuset is configured, it breaks the strict hugetlb page