Re: [PATCH v4 1/1] mm: introduce put_user_page*(), placeholder versions

[John Hubbard]

On 3/19/19 4:57 PM, Dave Chinner wrote:
> On Tue, Mar 19, 2019 at 06:06:55PM -0400, Jerome Glisse wrote:
>> On Wed, Mar 20, 2019 at 08:23:46AM +1100, Dave Chinner wrote:
>>> On Tue, Mar 19, 2019 at 10:14:16AM -0400, Jerome Glisse wrote:
>>>> On Tue, Mar 19, 2019 at 09:47:24AM -0400, Jerome Glisse wrote:
>>>>> On Tue, Mar 19, 2019 at 03:04:17PM +0300, Kirill A. Shutemov wrote:
>>>>>> On Fri, Mar 08, 2019 at 01:36:33PM -0800, john.hubbard@xxxxxxxxx wrote:
>>>>>>> From: John Hubbard <jhubbard@xxxxxxxxxx>
>>>>> [...]
>>>> Forgot to mention one thing, we had a discussion with Andrea and Jan
>>>> about set_page_dirty() and Andrea had the good idea of maybe doing
>>>> the set_page_dirty() at GUP time (when GUP with write) not when the
>>>> GUP user calls put_page(). We can do that by setting the dirty bit
>>>> in the pte for instance. They are few bonus of doing things that way:
>>>>     - amortize the cost of calling set_page_dirty() (ie one call for
>>>>       GUP and page_mkclean()
>>>>     - it is always safe to do so at GUP time (ie the pte has write
>>>>       permission and thus the page is in correct state)
>>>>     - safe from truncate race
>>>>     - no need to ever lock the page
>>>
>>> I seem to have missed this conversation, so please excuse me for
>>
>> The set_page_dirty() at GUP was in a private discussion (it started
>> on another topic and drifted away to set_page_dirty()).
>>
>>> asking a stupid question: if it's a file backed page, what prevents
>>> background writeback from cleaning the dirty page ~30s into a long
>>> term pin? i.e. I don't see anything in this proposal that prevents
>>> the page from being cleaned by writeback and putting us straight
>>> back into the situation where a long term RDMA is writing to a clean
>>> page....
>>
>> So this patchset does not solve this issue.
> 
> OK, so it just kicks the can further down the road.

Hi Dave,

My take on this is that all of the viable solution proposals so far require
tracking of gup-pinned pages. That's why I'm trying to get started now on 
at least the tracking aspects: it seems like the tracking part is now well
understood. And it does have some lead time, because I expect the call site
conversions probably have to go through various maintainers' trees.

However, if you are thinking that this is unwise, and that's it's smarter 
to wait until the entire design is completely worked out, I'm open to that,
too. 

Thoughts?

thanks,
-- 
John Hubbard
NVIDIA

> 
>>     [3..N] decide what to do for GUPed page, so far the plans seems
>>          to be to keep the page always dirty and never allow page
>>          write back to restore the page in a clean state. This does
>>          disable thing like COW and other fs feature but at least
>>          it seems to be the best thing we can do.
> 
> So the plan for GUP vs writeback so far is "break fsync()"? :)
> 
> We might need to work on that a bit more...
> 
> Cheers,
> 
> Dave.
>