linux-kernel - Re: [PATCH RFC 34/39] mm/rmap: introduce folio_try_dup_anon_rmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d3eb1e5-9fbb-487d-8fe9-066387671357@redhat.com>
Date:   Tue, 5 Dec 2023 15:12:14 +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 34/39] mm/rmap: introduce
 folio_try_dup_anon_rmap_[pte|ptes|pmd]()

On 05.12.23 15:02, Ryan Roberts wrote:
> On 05/12/2023 13:50, David Hildenbrand wrote:
>> On 05.12.23 14:40, Ryan Roberts wrote:
>>> On 05/12/2023 13:18, David Hildenbrand wrote:
>>>> On 05.12.23 14:17, David Hildenbrand wrote:
>>>>> On 05.12.23 14:12, Ryan Roberts wrote:
>>>>>> On 04/12/2023 14:21, David Hildenbrand wrote:
>>>>>>> The last user of page_needs_cow_for_dma() and __page_dup_rmap() are gone,
>>>>>>> remove them.
>>>>>>>
>>>>>>> Add folio_try_dup_anon_rmap_ptes() right away, we want to perform rmap
>>>>>>> baching during fork() soon.
>>>>>>>
>>>>>>> Signed-off-by: David Hildenbrand <david@...hat.com>
>>>>>>> ---
>>>>>>>      include/linux/mm.h   |   6 --
>>>>>>>      include/linux/rmap.h | 145 +++++++++++++++++++++++++++++--------------
>>>>>>>      2 files changed, 100 insertions(+), 51 deletions(-)
>>>>>>>
>>>>>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>>>>>> index 24c1c7c5a99c0..f7565b35ae931 100644
>>>>>>> --- a/include/linux/mm.h
>>>>>>> +++ b/include/linux/mm.h
>>>>>>> @@ -1964,12 +1964,6 @@ static inline bool folio_needs_cow_for_dma(struct
>>>>>>> vm_area_struct *vma,
>>>>>>>          return folio_maybe_dma_pinned(folio);
>>>>>>>      }
>>>>>>>      -static inline bool page_needs_cow_for_dma(struct vm_area_struct *vma,
>>>>>>> -                      struct page *page)
>>>>>>> -{
>>>>>>> -    return folio_needs_cow_for_dma(vma, page_folio(page));
>>>>>>> -}
>>>>>>> -
>>>>>>>      /**
>>>>>>>       * is_zero_page - Query if a page is a zero page
>>>>>>>       * @page: The page to query
>>>>>>> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
>>>>>>> index 21d72cc602adc..84439f7720c62 100644
>>>>>>> --- a/include/linux/rmap.h
>>>>>>> +++ b/include/linux/rmap.h
>>>>>>> @@ -354,68 +354,123 @@ static inline void folio_dup_file_rmap_pmd(struct
>>>>>>> folio *folio,
>>>>>>>      #endif
>>>>>>>      }
>>>>>>>      -static inline void __page_dup_rmap(struct page *page, bool compound)
>>>>>>> +static inline int __folio_try_dup_anon_rmap(struct folio *folio,
>>>>>>
>>>>>> __always_inline?
>>>>>
>>>>> Yes.
>>>>
>>>> Ah, no, I did this for a reason. This function lives in a header, so it will
>>>> always be inlined.
>>>>
>>>
>>> Really? It will certainly be duplicated across every compilation unit, but
>>> that's separate from being inlined - if the optimizer is off, won't it just end
>>> up as an out-of-line function in every compilation unit?
>>
>> Good point, I didn't really consider that here, and thinking about it it makes
>> perfect sense.
>>
>> I think the compiler might even ignore "always_inline". I read that especially
>> with recursion the compiler might ignore that. But people can then complain to
>> the compiler writers about performance issues here, we told the compiler what we
>> think is best.
>>
> 
> To be honest, my comment assumed that you had a good reason for using
> __always_inline, and in that case then you should be consistent. But if you
> don't have a good reason, you should probably just use inline and let the
> compiler do what it thinks best?

I think __always_inline is the right thing to do here, we really want 
the compiler to generate specialized code. I was just somehow ignoring 
the scenario you described :)

__always_inline it is.

-- 
Cheers,

David / dhildenb