Re: [dpdk-dev] [PATCH 1/2] eal/malloc: merge malloc_elems in heap if they are contiguous

[gowrishankar muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>]

Hi Anatoly,

On Friday 04 May 2018 02:59 PM, Burakov, Anatoly wrote:
> On 03-May-18 11:11 AM, Gowrishankar wrote:
>> From: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
>>
>> During malloc heap init, if there are malloc_elems contiguous in
>> virt addresses, they could be merged so that, merged malloc_elem
>> would guarantee larger free memory size than its actual hugepage
>> size, it was created for.
>>
>> Fixes: fafcc11985 ("mem: rework memzone to be allocated by malloc")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Gowrishankar Muthukrishnan 
>> <gowrishankar.m@linux.vnet.ibm.com>
>> ---
>
> Hi Gowrishankar,
>
> I haven't looked at the patchset in detail yet, however i have a 
> general question: how do we end up with VA-contiguous memsegs that are 
> not part of the same memseg in the first place? Is there something 
> wrong with memseg sorting code? Alternatively, if 
> they were broken up, presumably they were broken up for a reason, 
> namely while they may be VA contiguous, they weren't IOVA-contiguous.

In powerpc, when *nr_overcommit_hugepages set* (to respect address hint 
in get_virtual_area() as requested by secondary process), mmap() would 
not be allocate one big VA chunk for all the available hugepages. In 
order to support secondary process be in same VA
range, we need to add anonymous and hugetlb flags in mmap calls while 
remapping. As mmap can only create max VA at the size of hugepage 
(MAP_HUGETLB) and also to respect address hint (MAP_ANONYMOUS), multiple 
VA chunks are created, even though both VA and IOVA are contiguous in 
most of the cases.

>
> Can you provide a dump of physmem layout where memory would have been 
> VA and IOVA-contiguous while belonging to different memsegs?

Please find here: https://pastebin.com/tDNEaxdU

As you notice malloc_heaps, its index for heap size is 8 which is 
supposedly 11.

To note, these are not problems with memory rework done in latest code 
base. So, I refered code until v18.02.

-- 
Regards,
Gowrishankar M