Re: [patch 13/15] mm/page_owner: align with pageblock_nr pages

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

 



On 12/05/2017 12:22 PM, Vlastimil Babka wrote:
> On 12/04/2017 01:56 PM, zhong jiang wrote:
>> On 2017/12/4 20:35, Michal Hocko wrote:
>>> On Mon 04-12-17 20:23:49, zhong jiang wrote:
>>>> On 2017/12/4 20:01, Michal Hocko wrote:
>>>>> On Mon 04-12-17 19:51:12, zhong jiang wrote:
>>>>>> On 2017/12/2 1:15, Michal Hocko wrote:
>>>>>>> On Fri 01-12-17 17:58:28, Vlastimil Babka wrote:
>>>>>>>> On 11/30/2017 11:15 PM, akpm@xxxxxxxxxxxxxxxxxxxx wrote:
>>>>>>>>> From: zhong jiang <zhongjiang@xxxxxxxxxx>
>>>>>>>>> Subject: mm/page_owner: align with pageblock_nr pages
>>>>>>>>>
>>>>>>>>> When pfn_valid(pfn) returns false, pfn should be aligned with
>>>>>>>>> pageblock_nr_pages other than MAX_ORDER_NR_PAGES in init_pages_in_zone,
>>>>>>>>> because the skipped 2M may be valid pfn, as a result, early allocated
>>>>>>>>> count will not be accurate.
>>>>>>>>>
>>>>>>>>> Link: http://lkml.kernel.org/r/1468938136-24228-1-git-send-email-zhongjiang@xxxxxxxxxx
>>>>>>>>> Signed-off-by: zhong jiang <zhongjiang@xxxxxxxxxx>
>>>>>>>>> Cc: Michal Hocko <mhocko@xxxxxxxxxx>
>>>>>>>>> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>>>>>>>> The author never responded and Michal Hocko basically NAKed it in
>>>>>>>> https://lkml.kernel.org/r/<20160812130727.GI3639@xxxxxxxxxxxxxx>
>>>>>>>> I think we should drop it.
>>>>>>> Or extend the changelog to actually describe what kind of problem it
>>>>>>> fixes and do an additional step to unigy
>>>>>>> MAX_ORDER_NR_PAGES/pageblock_nr_pages
>>>>>>>  
>>>>>>   Hi, Michal
>>>>>>    
>>>>>>         IIRC,  I had explained the reason for patch.  if it not. I am so sorry for that.
>>>>>>     
>>>>>>         when we select MAX_ORDER_NR_PAGES,   the second 2M will be skiped.
>>>>>>        it maybe result in normal pages leak.
>>>>>>
>>>>>>         meanwhile.  as you had said.  it make the code consistent.  why do not we do it.
>>>>>>    
>>>>>>         I think it is reasonable to upstream the patch.  maybe I should rewrite the changelog
>>>>>>        and repost it.
>>>>>>
>>>>>>     Michal,  Do you think ?
>>>>> Yes, rewrite the patch changelog and make it _clear_ what it fixes and
>>>>> under _what_ conditions. There are also other places using
>>>>> MAX_ORDER_NR_PAGES rathern than pageblock_nr_pages. Do they need to be
>>>>> updated as well?
>>>>  in the lastest kernel.  according to correspond context,   I  can not find the candidate. :-)
>>> git grep says some in page_ext.c, memory_hotplug.c and few in the arch
>>> code. I belive we really want to describe and document the distinction
>>> between the two constants and explain when to use which one.
>>>
>>  yes,   limited by my knowledge and english.  Maybe Vlastimil  can  address it  in detail.  
> 
> Hi, on a fresh look, I believe this patch doesn't improve anything in
> practice. It potentially makes init_pages_in_zone() catch more early
> allocations, if a hole happens to be placed in the beginning of
> MAX_ORDER block, and the following pageblock within the block was early
> allocated.
> 
> However, read_page_owner() skips whole MAX_ORDER block as well in this
> situation, so we won't be able to read the info anyway...
> 
> Also the problem is not as simple as documenting MAX_ORDER_NR_PAGES vs
> pabeblock_nr_pages. We discussed it year ago when this patch was first
> posted, how skipping over holes would have to be made more robust, and
> how architectures should define hole granularity to avoid checking each
> individual pfn in what appears to be a hole, to see if the hole has ended.

OK, let's see. There are three archs that define CONFIG_HOLES_IN_ZONE.
This means for those arches, pfn_valid_within() is not defined as true,
but calls actual pfn_valid():

arm64 - pfn_valid(pfn) is memblock_is_map_memory(pfn << PAGE_SHIFT)
What is the granularity of memblock allocator? If it's less than
MAX_ORDER, could we just sacrifice the memory in MAX_ORDER block that
has a hole inside?

mips - pfn_valid() is a simple pfn-within-boundaries comparison. That
shouldn't make any difference, if we observe zone end pfn right! They
added the config in 465aaed0030b2 for Cavium Octeon and apparently it
fixed a crash, but I wonder what was really going on then...

ia64 - uses ia64_pfn_valid() which I have no idea what it does...

> 
>> Thanks
>> zhongjiang
>>
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[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