[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <873e12ec-c153-445c-aaa3-a68c59a01fe8@redhat.com>
Date: Tue, 5 Dec 2023 13:26:50 +0100
From: David Hildenbrand <david@...hat.com>
To: Ryan Roberts <ryan.roberts@....com>, linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Hugh Dickins <hughd@...gle.com>,
Yin Fengwei <fengwei.yin@...el.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Muchun Song <muchun.song@...ux.dev>,
Peter Xu <peterx@...hat.com>
Subject: Re: [PATCH RFC 15/39] mm/huge_memory: batch rmap operations in
__split_huge_pmd_locked()
On 05.12.23 13:22, Ryan Roberts wrote:
> On 04/12/2023 14:21, David Hildenbrand wrote:
>> Let's use folio_add_anon_rmap_ptes(), batching the rmap operations.
>>
>> While at it, use more folio operations (but only in the code branch we're
>> touching), use VM_WARN_ON_FOLIO(), and pass RMAP_COMPOUND instead of
>
> You mean RMAP_EXCLUSIVE?
Indeed.
[...]
>> - if (!freeze)
>> - page_ref_add(page, HPAGE_PMD_NR - 1);
>> + if (!freeze) {
>> + rmap_t rmap_flags = RMAP_NONE;
>> +
>> + folio_ref_add(folio, HPAGE_PMD_NR - 1);
>> + if (anon_exclusive)
>> + rmap_flags = RMAP_EXCLUSIVE;
>
> nit: I'd be inclined to make this |= since you're accumulating optional falgs.
> Yes, its the only one so it still works as is...
Make sense!
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists