On 19.07.22 17:43, Michal Hocko wrote: > On Tue 19-07-22 20:42:42, Charan Teja Kalla wrote: >> Thanks Michal!! >> >> On 7/18/2022 8:24 PM, Michal Hocko wrote: > [...] >>>>>> diff --git a/mm/page_ext.c b/mm/page_ext.c >>>>>> index 3dc715d..5ccd3ee 100644 >>>>>> --- a/mm/page_ext.c >>>>>> +++ b/mm/page_ext.c >>>>>> @@ -299,8 +299,9 @@ static void __free_page_ext(unsigned long pfn) >>>>>> if (!ms || !ms->page_ext) >>>>>> return; >>>>>> base = get_entry(ms->page_ext, pfn); >>>>>> - free_page_ext(base); >>>>>> ms->page_ext = NULL; >>>>>> + synchronize_rcu(); >>>>>> + free_page_ext(base); >>>>>> } >>>>> So you are imposing the RCU grace period for each page_ext! This can get >>>>> really expensive. Have you tried to measure the effect? >>> I was wrong here! This is for each memory section which is not as >>> terrible as every single page_ext. This can be still quite a lot memory >>> sections in a single memory block (e.g. on ppc memory sections are >>> ridiculously small). >>> >> >> On the ARM64, I see that the minimum a section size will go is 128MB. I >> think 16MB is the section size on ppc. Any inputs on how frequently >> offline/online operation is being done on this ppc arch? > > I have seen several reports where 16MB sections were used on PPC LPARs > with a non trivial size. My usual answer to that is tha this is mostly a > self inflicted injury but I am told that for some reasons I cannot > udnerstand this is not easy to change. So reasonable or not this is not > all that uncommon in PPC land. > > We definitely shouldn't optimize for those setups but we shouldn't make > them suffer even more as well. Besides that it seems that a single > rcu_synchronize per offline operation should be doable. IIRC, any reasonable PPC64 installation uses LMB >= 256 MiB, which maps to the logical memory block size, and we only online/offline complete memory blocks, not individual memory sections. So one these installations, you'll see memory getting onlined/offlined in at least 256MiB granularity. -- Thanks, David / dhildenb
