From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by dpdk.org (Postfix) with ESMTP id 2D8A123C for ; Fri, 4 May 2018 12:41:48 +0200 (CEST) Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w44Adm6a094722 for ; Fri, 4 May 2018 06:41:47 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hrh3150rm-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 04 May 2018 06:41:47 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 May 2018 11:41:45 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 4 May 2018 11:41:42 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w44AfgU265732672; Fri, 4 May 2018 10:41:42 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 944724C044; Fri, 4 May 2018 11:33:49 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7FDA24C050; Fri, 4 May 2018 11:33:48 +0100 (BST) Received: from [9.124.35.116] (unknown [9.124.35.116]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 4 May 2018 11:33:48 +0100 (BST) To: "Burakov, Anatoly" , Sergio Gonzalez Monroy Cc: dev@dpdk.org, Thomas Monjalon , stable@dpdk.org, Chao Zhu References: <68d1bc7b-a90d-2adc-c98b-560276589b15@intel.com> From: gowrishankar muthukrishnan Date: Fri, 4 May 2018 16:11:40 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <68d1bc7b-a90d-2adc-c98b-560276589b15@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-TM-AS-GCONF: 00 x-cbid: 18050410-0040-0000-0000-00000435F19D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18050410-0041-0000-0000-0000263A19E2 Message-Id: <78f363f1-79d8-0369-05eb-8f853d9c76a5@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-04_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805040098 Subject: Re: [dpdk-dev] [PATCH 1/2] eal/malloc: merge malloc_elems in heap if they are contiguous X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 10:41:48 -0000 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 >> >> 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 >> >> --- > > 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