From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: David Hildenbrand <david@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>,
akpm@linux-foundation.org, hughd@google.com
Cc: willy@infradead.org, 21cnbao@gmail.com, ziy@nvidia.com,
ioworker0@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()
Date: Fri, 26 Jul 2024 09:09:30 +0800 [thread overview]
Message-ID: <3bd0c129-fdca-4f30-b5a6-c0b8d997d3e6@linux.alibaba.com> (raw)
In-Reply-To: <1e635cfd-d461-4e56-95b8-c6ea512f64ca@redhat.com>
On 2024/7/25 21:09, David Hildenbrand wrote:
>>>> /*
>>>> @@ -1625,27 +1632,39 @@ static gfp_t limit_gfp_mask(gfp_t huge_gfp,
>>>> gfp_t limit_gfp)
>>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>> unsigned long shmem_allowable_huge_orders(struct inode *inode,
>>>> struct vm_area_struct *vma, pgoff_t index,
>>>> - bool global_huge)
>>>> + bool shmem_huge_force)
>>>> {
>>>> unsigned long mask = READ_ONCE(huge_shmem_orders_always);
>>>> unsigned long within_size_orders =
>>>> READ_ONCE(huge_shmem_orders_within_size);
>>>> - unsigned long vm_flags = vma->vm_flags;
>>>> + unsigned long vm_flags = vma ? vma->vm_flags : 0;
>>>> + struct mm_struct *fault_mm = vma ? vma->vm_mm : NULL;
>>>
>>> nit: rather than deriving the fault_mm here, I wonder if its cleaner
>>> to just
>>> pass vma to shmem_huge_global_enabled()? shmem_huge_global_enabled()
>>> is just
>>> using it as a guard to access vm_flags, which you can just as easily
>>> do by
>>> testing the vma for non-NULL. And you can access mm flags with
>>> vma->vm_mm->flags
>>> after testing the vma too.
>>
>> Make sense to me, and will do in next version.
>
> Feel free to add my
>
> Acked-by: David Hildenbrand <david@redhat.com>
Thanks David.
Andrew has already queued my v3 patchset into the mm-unstable branch.
Andrew, please help to add David's acked tag for v3 series. Thanks.
next prev parent reply other threads:[~2024-07-26 1:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-13 13:24 [PATCH v2 0/3] Some cleanups for shmem Baolin Wang
2024-07-13 13:24 ` [PATCH v2 1/3] mm: shmem: simplify the suitable huge orders validation for tmpfs Baolin Wang
2024-07-15 13:30 ` Ryan Roberts
2024-07-25 13:07 ` David Hildenbrand
2024-07-13 13:24 ` [PATCH v2 2/3] mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled() Baolin Wang
2024-07-15 13:32 ` Ryan Roberts
2024-07-25 13:08 ` David Hildenbrand
2024-07-13 13:24 ` [PATCH v2 3/3] mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders() Baolin Wang
2024-07-15 13:36 ` Ryan Roberts
2024-07-22 2:41 ` Baolin Wang
2024-07-25 13:09 ` David Hildenbrand
2024-07-26 1:09 ` Baolin Wang [this message]
2024-07-24 19:14 ` [PATCH v2 0/3] Some cleanups for shmem Andrew Morton
2024-07-24 19:15 ` Andrew Morton
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=3bd0c129-fdca-4f30-b5a6-c0b8d997d3e6@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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