All of lore.kernel.org
 help / color / mirror / Atom feed
From: jane.chu@oracle.com
To: Oscar Salvador <osalvador@suse.de>
Cc: akpm@linux-foundation.org, david@kernel.org,
	muchun.song@linux.dev, lorenzo.stoakes@oracle.com,
	Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org,
	surenb@google.com, mhocko@suse.com, corbet@lwn.net,
	skhan@linuxfoundation.org, hughd@google.com,
	baolin.wang@linux.alibaba.com, peterx@redhat.com,
	linux-mm@kvack.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] hugetlb: make hugetlb_fault_mutex_hash() take PAGE_SIZE index
Date: Mon, 13 Apr 2026 14:32:46 -0700	[thread overview]
Message-ID: <dde32efa-e02e-4e44-a705-f558e0caa869@oracle.com> (raw)
In-Reply-To: <ad0rUB4FuNUOJ1pN@localhost.localdomain>



On 4/13/2026 10:43 AM, Oscar Salvador wrote:
> On Thu, Apr 09, 2026 at 05:41:54PM -0600, Jane Chu wrote:
>> hugetlb_fault_mutex_hash() is used to serialize faults and page cache
>> operations on the same hugetlb file offset. The helper currently expects
>> its index argument in hugetlb page granularity, so callers have to
>> open-code conversions from the PAGE_SIZE-based indices commonly used
>> in the rest of MM helpers.
>>
>> Change hugetlb_fault_mutex_hash() to take a PAGE_SIZE-based index
>> instead, and perform the hugetlb-granularity conversion inside the helper.
>> Update all callers accordingly.
>>
>> This makes the helper interface consistent with filemap_get_folio(),
>> and linear_page_index(), while preserving the same lock selection for
>> a given hugetlb file offset.
>>
>> Signed-off-by: Jane Chu <jane.chu@oracle.com>
>> ---
>>   fs/hugetlbfs/inode.c | 19 ++++++++++---------
>>   mm/hugetlb.c         | 28 +++++++++++++++++++---------
>>   mm/memfd.c           | 11 ++++++-----
>>   mm/userfaultfd.c     |  7 +++----
>>   4 files changed, 38 insertions(+), 27 deletions(-)
>>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index cf79fb830377..e24e9bf54e14 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -575,7 +575,7 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
>>   	struct address_space *mapping = &inode->i_data;
>>   	const pgoff_t end = lend >> PAGE_SHIFT;
>>   	struct folio_batch fbatch;
>> -	pgoff_t next, index;
>> +	pgoff_t next, idx;
>>   	int i, freed = 0;
>>   	bool truncate_op = (lend == LLONG_MAX);
>>   
>> @@ -586,15 +586,15 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
>>   			struct folio *folio = fbatch.folios[i];
>>   			u32 hash = 0;
>>   
>> -			index = folio->index >> huge_page_order(h);
>> -			hash = hugetlb_fault_mutex_hash(mapping, index);
>> +			hash = hugetlb_fault_mutex_hash(mapping, folio->index);
>>   			mutex_lock(&hugetlb_fault_mutex_table[hash]);
>>   
>>   			/*
>>   			 * Remove folio that was part of folio_batch.
>>   			 */
>> +			idx = folio->index >> huge_page_order(h);
>>   			remove_inode_single_folio(h, inode, mapping, folio,
>> -						  index, truncate_op);
>> +						  idx, truncate_op);
> 
> Since this is the only place we call remove_inode_single_folio(), and that we do not
> the index (at least index >> huge_page_order()) directly in this function, would it not be
> better to make remove_inode_single_folio do the conversion itself?

In PATCH 6/6, remove_inode_hugepages() is changed to call 
remove_inode_single_folio() passing "folio->index" directly,
thus eliminating the above conversion altogether.
I apologize for dividing up the patches this way, function by function,
for my convenience, introduced some temporary changes.  The overall 
resulted code hopefully is clearer.

> 
> Also, I am thinking out loud here but we do have a few places where we
> go: idx = index >> huge_page_order() to convert it into hugepage units, but the casual
> reader might be a bit puzzled about that.
> So, would it be worth to have implement an inline helper with an accurate name
> to do that? It might help whoever reads that?
> 

Indeed, will add below inline helpers -
   pgoff_t  huge_to_base(pgoff_t idx);
   pgoff_t  base_to_huge(pgoff_t index);

thanks!
-jane



  reply	other threads:[~2026-04-13 21:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 23:41 [PATCH 0/6] hugetlb: normalize exported interfaces to use base-page indices Jane Chu
2026-04-09 23:41 ` [PATCH 1/6] hugetlb: open-code hugetlb folio lookup index conversion Jane Chu
2026-04-11 14:14   ` Mike Rapoport
2026-04-13 16:39     ` jane.chu
2026-04-13 16:22   ` Oscar Salvador
2026-04-13 16:30     ` jane.chu
2026-04-20 18:27   ` Matthew Wilcox
2026-04-22 16:44     ` jane.chu
2026-04-23 14:55       ` Matthew Wilcox
2026-04-09 23:41 ` [PATCH 2/6] hugetlb: remove the hugetlb_linear_page_index() helper Jane Chu
2026-04-13 16:48   ` Oscar Salvador
2026-04-09 23:41 ` [PATCH 3/6] hugetlb: make hugetlb_fault_mutex_hash() take PAGE_SIZE index Jane Chu
2026-04-10 11:24   ` Usama Arif
2026-04-10 17:51     ` jane.chu
2026-04-13 17:43   ` Oscar Salvador
2026-04-13 21:32     ` jane.chu [this message]
2026-04-09 23:41 ` [PATCH 4/6] hugetlb: drop vma_hugecache_offset() in favor of linear_page_index() Jane Chu
2026-04-14  9:53   ` Oscar Salvador
2026-04-14 17:14     ` jane.chu
2026-04-09 23:41 ` [PATCH 5/6] hugetlb: make hugetlb_add_to_page_cache() use PAGE_SIZE-based index Jane Chu
2026-04-14 10:23   ` Oscar Salvador
2026-04-09 23:41 ` [PATCH 6/6] hugetlb: pass hugetlb reservation ranges in base-page indices Jane Chu
2026-04-15  8:01   ` Oscar Salvador
2026-04-15 19:39     ` jane.chu
2026-04-10  6:45 ` [syzbot ci] Re: hugetlb: normalize exported interfaces to use " syzbot ci
2026-04-10 21:54   ` jane.chu
2026-04-15  8:03 ` [PATCH 0/6] " Oscar Salvador
2026-04-15 19:40   ` jane.chu

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=dde32efa-e02e-4e44-a705-f558e0caa869@oracle.com \
    --to=jane.chu@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=rppt@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.