On 2/4/21 12:11 AM, John Hubbard wrote:
> On 2/3/21 2:00 PM, Joao Martins wrote:
> ...
>> +void unpin_user_page_range_dirty_lock(struct page *page, unsigned long npages,
>> + bool make_dirty)
>> +{
>> + unsigned long index;
>> + struct page *head;
>> + unsigned int ntails;
>> +
>> + for_each_compound_range(index, &page, npages, head, ntails) {
>> + if (make_dirty && !PageDirty(head))
>> + set_page_dirty_lock(head);
>> + put_compound_head(head, ntails, FOLL_PIN);
>> + }
>> +}
>> +EXPORT_SYMBOL(unpin_user_page_range_dirty_lock);
>> +
>
> Also, looking at this again while trying to verify the sg diffs in patch #4, I noticed
> that the name is tricky. Usually a "range" would not have a single struct page* as the
> argument. So in this case, perhaps a comment above the function would help, something
> approximately like this:
>
> /*
> * The "range" in the function name refers to the fact that the page may be a
> * compound page. If so, then that compound page will be treated as one or more
> * ranges of contiguous tail pages.
> */
>
> ...I guess. Or maybe the name is just wrong (a comment block explaining a name is
> always a bad sign).
Naming aside, a comment is probably worth nonetheless to explain what the function does.
> Perhaps we should rename it to something like:
>
> unpin_user_compound_page_dirty_lock()
>
> ?
The thing though, is that it doesn't *only* unpin a compound page. It unpins a contiguous
range of pages (hence page_range) *and* if these are compound pages it further accelerates
things.
Albeit, your name suggestion then probably hints the caller that you should be passing a
compound page anyways, so your suggestion does have a ring to it.
Joao
