Re: [PATCH 1/4] mm: migrate: use a folio in add_page_for_migration()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Zi Yan <ziy@xxxxxxxxxx> writes:

> On 14 Aug 2023, at 23:56, Huang, Ying wrote:
>
>> Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> writes:
>>
>>> On 2023/8/4 10:42, Zi Yan wrote:
>>>> On 3 Aug 2023, at 21:45, Kefeng Wang wrote:
>>>>
>>>>> On 2023/8/3 20:30, Matthew Wilcox wrote:
>>>>>> On Thu, Aug 03, 2023 at 03:13:21PM +0800, Kefeng Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2023/8/2 20:21, Matthew Wilcox wrote:
>>>>>>>> On Wed, Aug 02, 2023 at 05:53:43PM +0800, Kefeng Wang wrote:
>>>>>>>>>     	err = -EACCES;
>>>>>>>>> -	if (page_mapcount(page) > 1 && !migrate_all)
>>>>>>>>> -		goto out_putpage;
>>>>>>>>> +	if (folio_estimated_sharers(folio) > 1 && !migrate_all)
>>>>>>>>> +		goto out_putfolio;
>>>>>>>>
>>>>>>>> I do not think this is the correct change.  Maybe leave this line
>>>>>>>> alone.
>>>>>>>
>>>>>>> Ok, I am aware of the discussion about this in other mail, will not
>>>>>>> change it(also the next two patch about this function), or wait the
>>>>>>> new work of David.
>>>>>>>>
>>>>>>>>> -	if (PageHuge(page)) {
>>>>>>>>> -		if (PageHead(page)) {
>>>>>>>>> -			isolated = isolate_hugetlb(page_folio(page), pagelist);
>>>>>>>>> +	if (folio_test_hugetlb(folio)) {
>>>>>>>>> +		if (folio_test_large(folio)) {
>>>>>>>>
>>>>>>>> This makes no sense when you read it.  All hugetlb folios are large,
>>>>>>>> by definition.  Think about what this code used to do, and what it
>>>>>>>> should be changed to.
>>>>>>>
>>>>>>> hugetlb folio is self large folio, will drop redundant check
>>>>>>
>>>>>> No, that's not the difference.  Keep thinking about it.  This is not
>>>>>> a mechanical translation!
>>>>>
>>>>>
>>>>>    if (PageHuge(page))  // page must be a hugetlb page
>>>>> 	if (PageHead(page)) // page must be a head page, not tail
>>>>>               isolate_hugetlb() // isolate the hugetlb page if head
>>>>>
>>>>> After using folio,
>>>>>
>>>>>    if (folio_test_hugetlb(folio)) // only check folio is hugetlb or not
>>>>>
>>>>> I don't check the page is head or not, since the follow_page could
>>>>> return a sub-page, so the check PageHead need be retained, right?
>>>> Right. It will prevent the kernel from trying to isolate the same
>>>> hugetlb page
>>>> twice when two pages are in the same hugetlb folio. But looking at the
>>>> code, if you try to isolate an already-isolated hugetlb folio, isolate_hugetlb()
>>>> would return false, no error would show up. But it changes err value
>>>> from -EACCES to -EBUSY and user will see a different page status than before.
>>>
>>>
>>> When check man[1], the current -EACCES is not right, -EBUSY is not
>>> precise but more suitable for this scenario,
>>>
>>>  	-EACCES
>>>               The page is mapped by multiple processes and can be moved
>>>               only if MPOL_MF_MOVE_ALL is specified.
>>>
>>>        -EBUSY The page is currently busy and cannot be moved.  Try again
>>>               later.  This occurs if a page is undergoing I/O or another
>>>               kernel subsystem is holding a reference to the page.
>>> 	-ENOENT
>>>               The page is not present.
>>>
>>>> I wonder why we do not have follow_folio() and returns -ENOENT error
>>>> pointer
>>>> when addr points to a non head page. It would make this patch more folio if
>>>> follow_folio() can be used in place of follow_page(). One caveat is that
>>>> user will see -ENOENT instead of -EACCES after this change.
>>>>
>>>
>>> -ENOENT is ok, but maybe the man need to be updated too.
>>>
>>>
>>> 	
>>> [1] https://man7.org/linux/man-pages/man2/move_pages.2.html
>>>
>>
>> I don't think -ENOENT is appropriate.  IIUC, -ENOENT means no need to
>> migrate.  Which isn't the case here apparently.
>
> Are you referring to a comment or the man page? The man page says
> -ENOENT means the page is not present. Or you think it also implies
> there is no need to migrate? If yes, we probably need to update the man
> page.

Is it possible that a page isn't present, but we need to migrate it?

--
Best Regards,
Huang, Ying




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux