linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yin Fengwei <fengwei.yin@intel.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: <linux-mm@kvack.org>, <akpm@linux-foundation.org>,
	<willy@infradead.org>, <yuzhao@google.com>,
	<ryan.roberts@arm.com>
Subject: Re: [PATCH v2 1/2] THP: avoid lock when check whether THP is in deferred list
Date: Wed, 26 Apr 2023 09:48:03 +0800	[thread overview]
Message-ID: <a8d290cc-c930-6cea-45da-3015d77fb25d@intel.com> (raw)
In-Reply-To: <87wn1ze983.fsf@yhuang6-desk2.ccr.corp.intel.com>



On 4/26/23 09:13, Huang, Ying wrote:
> Yin Fengwei <fengwei.yin@intel.com> writes:
> 
>> free_transhuge_page() acquires split queue lock then check
>> whether the THP was added to deferred list or not.
>>
>> It's safe to check whether the THP is in deferred list or not.
>>    When code hit free_transhuge_page(), there is no one tries
>>    to update the folio's _deferred_list.
> 
> I think that it's clearer to enumerate all places pages are added and
> removed from deferred list.  Then we can find out whether there's code
> path that may race with this.
> 
> Take a glance at the search result of `grep split_queue_lock -r mm`.  It
> seems that deferred_split_scan() may race with free_transhuge_page(), so
> we need to recheck with the lock held as Kirill pointed out.
My understanding is the check after take the lock is not necessary. See
my reply to Kirill. Thanks.


Regards
Yin, Fengwei

> 
> Best Regards,
> Huang, Ying
> 
>>    If folio is not in deferred_list, it's safe to check without
>>    acquiring lock.
>>
>>    If folio is in deferred_list, the other node in deferred_list
>>    adding/deleteing doesn't impact the return value of
>>    list_epmty(@folio->_deferred_list).
>>
>> Running page_fault1 of will-it-scale + order 2 folio for anonymous
>> mapping with 96 processes on an Ice Lake 48C/96T test box, we could
>> see the 61% split_queue_lock contention:
>> -   71.28%     0.35%  page_fault1_pro  [kernel.kallsyms]           [k]
>>     release_pages
>>    - 70.93% release_pages
>>       - 61.42% free_transhuge_page
>>          + 60.77% _raw_spin_lock_irqsave
>>
>> With this patch applied, the split_queue_lock contention is less
>> than 1%.
>>
>> Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
>> Tested-by: Ryan Roberts <ryan.roberts@arm.com>
>> ---
>>  mm/huge_memory.c | 19 ++++++++++++++++---
>>  1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 032fb0ef9cd1..c620f1f12247 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -2799,12 +2799,25 @@ void free_transhuge_page(struct page *page)
>>  	struct deferred_split *ds_queue = get_deferred_split_queue(folio);
>>  	unsigned long flags;
>>  
>> -	spin_lock_irqsave(&ds_queue->split_queue_lock, flags);
>> -	if (!list_empty(&folio->_deferred_list)) {
>> +	/*
>> +	 * At this point, there is no one trying to queue the folio
>> +	 * to deferred_list. folio->_deferred_list is not possible
>> +	 * being updated.
>> +	 *
>> +	 * If folio is already added to deferred_list, add/delete to/from
>> +	 * deferred_list will not impact list_empty(&folio->_deferred_list).
>> +	 * It's safe to check list_empty(&folio->_deferred_list) without
>> +	 * acquiring the lock.
>> +	 *
>> +	 * If folio is not in deferred_list, it's safe to check without
>> +	 * acquiring the lock.
>> +	 */
>> +	if (data_race(!list_empty(&folio->_deferred_list))) {
>> +		spin_lock_irqsave(&ds_queue->split_queue_lock, flags);
>>  		ds_queue->split_queue_len--;
>>  		list_del(&folio->_deferred_list);
>> +		spin_unlock_irqrestore(&ds_queue->split_queue_lock, flags);
>>  	}
>> -	spin_unlock_irqrestore(&ds_queue->split_queue_lock, flags);
>>  	free_compound_page(page);
>>  }


  reply	other threads:[~2023-04-26  1:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25  8:46 [PATCH v2 0/2] Reduce lock contention related with large folio Yin Fengwei
2023-04-25  8:46 ` [PATCH v2 1/2] THP: avoid lock when check whether THP is in deferred list Yin Fengwei
2023-04-25 12:38   ` Kirill A. Shutemov
2023-04-26  1:47     ` Yin Fengwei
2023-04-26  2:08     ` Yin Fengwei
2023-04-26  8:17       ` Ryan Roberts
2023-04-28  6:28     ` Yin, Fengwei
2023-04-28 14:02       ` Kirill A. Shutemov
2023-04-29  8:32         ` Yin, Fengwei
2023-04-29  8:46           ` Kirill A. Shutemov
2023-05-01  5:50             ` Yin, Fengwei
2023-04-26  1:13   ` Huang, Ying
2023-04-26  1:48     ` Yin Fengwei [this message]
2023-04-26  8:11   ` Ryan Roberts
2023-04-25  8:46 ` [PATCH v2 2/2] lru: allow large batched add large folio to lru list Yin Fengwei

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=a8d290cc-c930-6cea-45da-3015d77fb25d@intel.com \
    --to=fengwei.yin@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=yuzhao@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox