[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21958961-259f-4520-ae60-e234383945d7@redhat.com>
Date: Tue, 17 Jun 2025 15:58:28 +0200
From: David Hildenbrand <david@...hat.com>
To: Jason Gunthorpe <jgg@...pe.ca>, lizhe.67@...edance.com
Cc: alex.williamson@...hat.com, akpm@...ux-foundation.org, peterx@...hat.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v4 2/3] gup: introduce unpin_user_folio_dirty_locked()
On 17.06.25 15:45, David Hildenbrand wrote:
> On 17.06.25 15:42, Jason Gunthorpe wrote:
>> On Tue, Jun 17, 2025 at 12:18:20PM +0800, lizhe.67@...edance.com wrote:
>>
>>> @@ -360,12 +360,7 @@ void unpin_user_page_range_dirty_lock(struct page *page, unsigned long npages,
>>>
>>> for (i = 0; i < npages; i += nr) {
>>> folio = gup_folio_range_next(page, npages, i, &nr);
>>> - if (make_dirty && !folio_test_dirty(folio)) {
>>> - folio_lock(folio);
>>> - folio_mark_dirty(folio);
>>> - folio_unlock(folio);
>>> - }
>>> - gup_put_folio(folio, nr, FOLL_PIN);
>>> + unpin_user_folio_dirty_locked(folio, nr, make_dirty);
>>> }
>>
>> I don't think we should call an exported function here - this is a
>> fast path for rdma and iommfd, I don't want to see it degrade to save
>> three duplicated lines :\
>
> Any way to quantify? In theory, the compiler could still optimize this
> within the same file, no?
Looking at the compiler output, I think the compile is doing exactly that.
Unless my obdjump -D -S analysis skills are seriously degraded :)
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists