From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergio Gonzalez Monroy Subject: Re: [PATCH] eal/ppc: fix secondary process to map hugepages in correct order Date: Fri, 20 May 2016 11:25:06 +0100 Message-ID: <78ee10ce-9e41-6019-533c-ef0677ce337e@intel.com> References: <1457360003-30055-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <56F17454.3010907@intel.com> <20160322171046.GG20448@bricha3-MOBL3> <000101d1b244$4d74de40$e85e9ac0$@linux.vnet.ibm.com> <37841a7b-4443-3060-6e0c-a798d00f4aec@intel.com> <000601d1b273$8e261a60$aa724f20$@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: 'Gowrishankar' , dev@dpdk.org, 'David Marchand' To: Chao Zhu , 'Bruce Richardson' Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id F346DADAF for ; Fri, 20 May 2016 12:25:09 +0200 (CEST) In-Reply-To: <000601d1b273$8e261a60$aa724f20$@linux.vnet.ibm.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 20/05/2016 09:41, Chao Zhu wrote: > Sergio, > > The step 4 will not fail because each huge page will get an virtual add= ress finally, though it's a different address. If you take a look at the = function rte_eal_hugepage_init(), in the last loop, it uses both physical= address and virtual address to determine a new memory segment. This step= can make sure that the initialization is correct. What I want to say is,= this bug also influence the secondary process in function rte_eal_hugepa= ge_attach(). It can make the secondary process fail to init. I'm trying t= o figure out how to make it work. You are right, I misread the code. So basically because mmap ignores the hint to mmap on the requested addre= ss, by default we get VA maps in decreasing address order. Knowing that, PPC orders pages by decreasing physical address order so wh= en this happens we actually get hugepages in order in the "new" final_va. Not sure if that makes sense but I think I understand where you are=20 coming from. I think we need to document this as know issue and/or add comments regard= ing this behavior , basically calling out that all this "reverse-ordering"=20 is required because mmap fails to map on the requested VA. Thanks, Sergio > -----Original Message----- > From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy@intel.com] > Sent: 2016=E5=B9=B45=E6=9C=8820=E6=97=A5 16:01 > To: Chao Zhu ; 'Bruce Richardson' > Cc: 'Gowrishankar' ; dev@dpdk.org; '= David Marchand' > Subject: Re: [dpdk-dev] [PATCH] eal/ppc: fix secondary process to map h= ugepages in correct order > > On 20/05/2016 04:03, Chao Zhu wrote: >> Bruce, >> >> Recently, we find some bugs with mmap in PowerLinux. The mmap doesn't >> respect the address hints. In function get_virtual_area() in >> eal_memory.c, mmap get the free virtual address range as the address >> hint. However, when mapping the real memory in >> rte_eal_hugepage_init(), mmap doesn't return the same address as the >> requested address. When taking a look at the /proc//maps, the >> requested address range is free for use. With this bug, pre-allocate s= ome free space doesn't work. > Hi Chao, > > If I understand you correctly, the issue you are describing would cause= DPDK to fail initialization even with the reverse reordering that you ar= e doing for PPC. > > Basically (just showing relevant initialization steps): > 1. map_all_hugepages(..., orig=3D1) > - map all hugepages > 2. find physical address for each hugepage 3. sort by physical address = 4. map_all_hugepages(..., orig=3D0) > - Now we try to get big chunk of virtual address for a block of c= ontig hugepages > so we know we have that virtual address chunk available. > - Then we try to remap each page of that block of contig pages in= to that > virtual address chunk. > > So the issue you are describing would make step 4 fail regardless of th= e different ordering that PPC does. > I'm probably missing something, would you care to elaborate? > > Sergio > > >> We're trying to create some test case and report it as a bug to kernel >> community. >> >> Here's some logs: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> EAL: Ask a virtual area of 0x10000000 bytes >> EAL: Virtual area found at 0x3fffa7000000 (size =3D 0x10000000) >> EAL: map_all_hugepages, /mnt/huge/rtemap_52,paddr 0x3ca6000000 >> requested >> addr: 0x3fffa7000000 mmaped addr: 0x3efff0000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_53,paddr 0x3ca5000000 >> requested >> addr: 0x3fffa8000000 mmaped addr: 0x3effef000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_54,paddr 0x3ca4000000 >> requested >> addr: 0x3fffa9000000 mmaped addr: 0x3effee000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_55,paddr 0x3ca3000000 >> requested >> addr: 0x3fffaa000000 mmaped addr: 0x3effed000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_56,paddr 0x3ca2000000 >> requested >> addr: 0x3fffab000000 mmaped addr: 0x3effec000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_57,paddr 0x3ca1000000 >> requested >> addr: 0x3fffac000000 mmaped addr: 0x3effeb000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_58,paddr 0x3ca0000000 >> requested >> addr: 0x3fffad000000 mmaped addr: 0x3effea000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_59,paddr 0x3c9f000000 >> requested >> addr: 0x3fffae000000 mmaped addr: 0x3effe9000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_60,paddr 0x3c9e000000 >> requested >> addr: 0x3fffaf000000 mmaped addr: 0x3effe8000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_61,paddr 0x3c9d000000 >> requested >> addr: 0x3fffb0000000 mmaped addr: 0x3effe7000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_62, paddr 0x3c9c000000 >> requested >> addr: 0x3fffb1000000 mmaped addr: 0x3effe6000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_63, paddr 0x3c9b000000 >> requested >> addr: 0x3fffb2000000 mmaped addr: 0x3effe5000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_51, paddr 0x3c9a000000 >> requested >> addr: 0x3fffb3000000 mmaped addr: 0x3effe4000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_50, paddr 0x3c99000000 >> requested >> addr: 0x3fffb4000000 mmaped addr: 0x3effe3000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_49, paddr 0x3c98000000 >> requested >> addr: 0x3fffb5000000 mmaped addr: 0x3effe2000000 >> EAL: map_all_hugepages, /mnt/huge/rtemap_48, paddr 0x3c97000000 >> requested >> addr: 0x3fffb6000000 mmaped addr: 0x3effe1000000 >> >> # cat /proc/143765/maps >> 01000000-02000000 rw-s 00000000 00:27 61162550 >> /mnt/huge/rtemap_14 >> 02000000-03000000 rw-s 00000000 00:27 61162536 >> /mnt/huge/rtemap_0 >> 03000000-04000000 rw-s 00000000 00:27 61162537 >> /mnt/huge/rtemap_1 >> 04000000-05000000 rw-s 00000000 00:27 61162538 >> /mnt/huge/rtemap_2 >> 05000000-06000000 rw-s 00000000 00:27 61162539 >> /mnt/huge/rtemap_3 >> 06000000-07000000 rw-s 00000000 00:27 61162540 >> /mnt/huge/rtemap_4 >> 07000000-08000000 rw-s 00000000 00:27 61162541 >> /mnt/huge/rtemap_5 >> 08000000-09000000 rw-s 00000000 00:27 61162542 >> /mnt/huge/rtemap_6 >> 09000000-0a000000 rw-s 00000000 00:27 61162543 >> /mnt/huge/rtemap_7 >> 0a000000-0b000000 rw-s 00000000 00:27 61162544 >> /mnt/huge/rtemap_8 >> 0b000000-0c000000 rw-s 00000000 00:27 61162545 >> /mnt/huge/rtemap_9 >> 0c000000-0d000000 rw-s 00000000 00:27 61162546 >> /mnt/huge/rtemap_10 >> 0d000000-0e000000 rw-s 00000000 00:27 61162547 >> /mnt/huge/rtemap_11 >> 0e000000-0f000000 rw-s 00000000 00:27 61162548 >> /mnt/huge/rtemap_12 >> 0f000000-10000000 rw-s 00000000 00:27 61162549 >> /mnt/huge/rtemap_13 >> 10000000-101f0000 r-xp 00000000 08:32 6040458 >> /home/dpdk/build/app/test >> 101f0000-10220000 rw-p 001f0000 08:32 6040458 >> /home/dpdk/build/app/test >> 10220000-15c20000 rw-p 00000000 00:00 0 [heap] >> 20000000-21000000 rw-s 00000000 00:27 61162566 >> /mnt/huge/rtemap_30 >> 21000000-22000000 rw-s 00000000 00:27 61162567 >> /mnt/huge/rtemap_31 >> 22000000-23000000 rw-s 00000000 00:27 61162568 >> /mnt/huge/rtemap_32 >> 23000000-24000000 rw-s 00000000 00:27 61162569 >> /mnt/huge/rtemap_33 >> 24000000-25000000 rw-s 00000000 00:27 61162570 >> /mnt/huge/rtemap_34 >> 25000000-26000000 rw-s 00000000 00:27 61162571 >> /mnt/huge/rtemap_35 >> 26000000-27000000 rw-s 00000000 00:27 61162572 >> /mnt/huge/rtemap_36 >> 27000000-28000000 rw-s 00000000 00:27 61162573 >> /mnt/huge/rtemap_37 >> 28000000-29000000 rw-s 00000000 00:27 61162574 >> /mnt/huge/rtemap_38 >> 29000000-2a000000 rw-s 00000000 00:27 61162575 >> /mnt/huge/rtemap_39 >> 2a000000-2b000000 rw-s 00000000 00:27 61162576 >> /mnt/huge/rtemap_40 >> 2b000000-2c000000 rw-s 00000000 00:27 61162577 >> /mnt/huge/rtemap_41 >> 2c000000-2d000000 rw-s 00000000 00:27 61162578 >> /mnt/huge/rtemap_42 >> 2d000000-2e000000 rw-s 00000000 00:27 61162579 >> /mnt/huge/rtemap_43 >> 2e000000-2f000000 rw-s 00000000 00:27 61162580 >> /mnt/huge/rtemap_44 >> 2f000000-30000000 rw-s 00000000 00:27 61162581 >> /mnt/huge/rtemap_45 >> 30000000-31000000 rw-s 00000000 00:27 61162582 >> /mnt/huge/rtemap_46 >> 31000000-32000000 rw-s 00000000 00:27 61162583 >> /mnt/huge/rtemap_47 >> 32000000-33000000 rw-s 00000000 00:27 61162584 >> /mnt/huge/rtemap_48 >> 33000000-34000000 rw-s 00000000 00:27 61162585 >> /mnt/huge/rtemap_49 >> 34000000-35000000 rw-s 00000000 00:27 61162586 >> /mnt/huge/rtemap_50 >> 35000000-36000000 rw-s 00000000 00:27 61162587 >> /mnt/huge/rtemap_51 >> 36000000-37000000 rw-s 00000000 00:27 61162588 >> /mnt/huge/rtemap_52 >> 37000000-38000000 rw-s 00000000 00:27 61162589 >> /mnt/huge/rtemap_53 >> 38000000-39000000 rw-s 00000000 00:27 61162590 >> /mnt/huge/rtemap_54 >> 39000000-3a000000 rw-s 00000000 00:27 61162591 >> /mnt/huge/rtemap_55 >> 3a000000-3b000000 rw-s 00000000 00:27 61162592 >> /mnt/huge/rtemap_56 >> 3b000000-3c000000 rw-s 00000000 00:27 61162593 >> /mnt/huge/rtemap_57 >> 3c000000-3d000000 rw-s 00000000 00:27 61162594 >> /mnt/huge/rtemap_58 >> 3d000000-3e000000 rw-s 00000000 00:27 61162595 >> /mnt/huge/rtemap_59 >> 3e000000-3f000000 rw-s 00000000 00:27 61162596 >> /mnt/huge/rtemap_60 >> 3f000000-40000000 rw-s 00000000 00:27 61162597 >> /mnt/huge/rtemap_61 >> 40000000-41000000 rw-s 00000000 00:27 61162598 >> /mnt/huge/rtemap_62 >> 41000000-42000000 rw-s 00000000 00:27 61162599 >> /mnt/huge/rtemap_63 >> 3effb1000000-3effb2000000 rw-s 00000000 00:27 61162541 >> /mnt/huge/rtemap_5 >> 3effb2000000-3effb3000000 rw-s 00000000 00:27 61162540 >> /mnt/huge/rtemap_4 >> 3effb3000000-3effb4000000 rw-s 00000000 00:27 61162551 >> /mnt/huge/rtemap_15 >> 3effb4000000-3effb5000000 rw-s 00000000 00:27 61162538 >> /mnt/huge/rtemap_2 >> 3effb5000000-3effb6000000 rw-s 00000000 00:27 61162549 >> /mnt/huge/rtemap_13 >> 3effb6000000-3effb7000000 rw-s 00000000 00:27 61162544 >> /mnt/huge/rtemap_8 >> 3effb7000000-3effb8000000 rw-s 00000000 00:27 61162543 >> /mnt/huge/rtemap_7 >> 3effb8000000-3effb9000000 rw-s 00000000 00:27 61162548 >> /mnt/huge/rtemap_12 >> 3effb9000000-3effba000000 rw-s 00000000 00:27 61162537 >> /mnt/huge/rtemap_1 >> 3effba000000-3effbb000000 rw-s 00000000 00:27 61162550 >> /mnt/huge/rtemap_14 >> 3effbb000000-3effbc000000 rw-s 00000000 00:27 61162545 >> /mnt/huge/rtemap_9 >> 3effbc000000-3effbd000000 rw-s 00000000 00:27 61162546 >> /mnt/huge/rtemap_10 >> 3effbd000000-3effbe000000 rw-s 00000000 00:27 61162547 >> /mnt/huge/rtemap_11 >> 3effbe000000-3effbf000000 rw-s 00000000 00:27 61162539 >> /mnt/huge/rtemap_3 >> 3effbf000000-3effc0000000 rw-s 00000000 00:27 61162542 >> /mnt/huge/rtemap_6 >> 3effc0000000-3effc1000000 rw-s 00000000 00:27 61162536 >> /mnt/huge/rtemap_0 >> 3effc1000000-3effc2000000 rw-s 00000000 00:27 61162556 >> /mnt/huge/rtemap_20 >> 3effc2000000-3effc3000000 rw-s 00000000 00:27 61162552 >> /mnt/huge/rtemap_16 >> 3effc3000000-3effc4000000 rw-s 00000000 00:27 61162553 >> /mnt/huge/rtemap_17 >> 3effc4000000-3effc5000000 rw-s 00000000 00:27 61162554 >> /mnt/huge/rtemap_18 >> 3effc5000000-3effc6000000 rw-s 00000000 00:27 61162555 >> /mnt/huge/rtemap_19 >> 3effc6000000-3effc7000000 rw-s 00000000 00:27 61162567 >> /mnt/huge/rtemap_31 >> 3effc7000000-3effc8000000 rw-s 00000000 00:27 61162566 >> /mnt/huge/rtemap_30 >> 3effc8000000-3effc9000000 rw-s 00000000 00:27 61162558 >> /mnt/huge/rtemap_22 >> 3effc9000000-3effca000000 rw-s 00000000 00:27 61162557 >> /mnt/huge/rtemap_21 >> 3effca000000-3effcb000000 rw-s 00000000 00:27 61162560 >> /mnt/huge/rtemap_24 >> 3effcb000000-3effcc000000 rw-s 00000000 00:27 61162561 >> /mnt/huge/rtemap_25 >> 3effcc000000-3effcd000000 rw-s 00000000 00:27 61162564 >> /mnt/huge/rtemap_28 >> 3effcd000000-3effce000000 rw-s 00000000 00:27 61162559 >> /mnt/huge/rtemap_23 >> 3effce000000-3effcf000000 rw-s 00000000 00:27 61162563 >> /mnt/huge/rtemap_27 >> 3effcf000000-3effd0000000 rw-s 00000000 00:27 61162562 >> /mnt/huge/rtemap_26 >> 3effd0000000-3effd1000000 rw-s 00000000 00:27 61162565 >> /mnt/huge/rtemap_29 >> 3effd1000000-3effd2000000 rw-s 00000000 00:27 61162572 >> /mnt/huge/rtemap_36 >> 3effd2000000-3effd3000000 rw-s 00000000 00:27 61162568 >> /mnt/huge/rtemap_32 >> 3effd3000000-3effd4000000 rw-s 00000000 00:27 61162569 >> /mnt/huge/rtemap_33 >> 3effd4000000-3effd5000000 rw-s 00000000 00:27 61162570 >> /mnt/huge/rtemap_34 >> 3effd5000000-3effd6000000 rw-s 00000000 00:27 61162571 >> /mnt/huge/rtemap_35 >> 3effd6000000-3effd7000000 rw-s 00000000 00:27 61162583 >> /mnt/huge/rtemap_47 >> 3effd7000000-3effd8000000 rw-s 00000000 00:27 61162582 >> /mnt/huge/rtemap_46 >> 3effd8000000-3effd9000000 rw-s 00000000 00:27 61162581 >> /mnt/huge/rtemap_45 >> 3effd9000000-3effda000000 rw-s 00000000 00:27 61162580 >> /mnt/huge/rtemap_44 >> 3effda000000-3effdb000000 rw-s 00000000 00:27 61162579 >> /mnt/huge/rtemap_43 >> 3effdb000000-3effdc000000 rw-s 00000000 00:27 61162578 >> /mnt/huge/rtemap_42 >> 3effdc000000-3effdd000000 rw-s 00000000 00:27 61162577 >> /mnt/huge/rtemap_41 >> 3effdd000000-3effde000000 rw-s 00000000 00:27 61162574 >> /mnt/huge/rtemap_38 >> 3effde000000-3effdf000000 rw-s 00000000 00:27 61162573 >> /mnt/huge/rtemap_37 >> 3effdf000000-3effe0000000 rw-s 00000000 00:27 61162575 >> /mnt/huge/rtemap_39 >> 3effe0000000-3effe1000000 rw-s 00000000 00:27 61162576 >> /mnt/huge/rtemap_40 >> 3effe1000000-3effe2000000 rw-s 00000000 00:27 61162584 >> /mnt/huge/rtemap_48 >> 3effe2000000-3effe3000000 rw-s 00000000 00:27 61162585 >> /mnt/huge/rtemap_49 >> 3effe3000000-3effe4000000 rw-s 00000000 00:27 61162586 >> /mnt/huge/rtemap_50 >> 3effe4000000-3effe5000000 rw-s 00000000 00:27 61162587 >> /mnt/huge/rtemap_51 >> 3effe5000000-3effe6000000 rw-s 00000000 00:27 61162599 >> /mnt/huge/rtemap_63 >> 3effe6000000-3effe7000000 rw-s 00000000 00:27 61162598 >> /mnt/huge/rtemap_62 >> 3effe7000000-3effe8000000 rw-s 00000000 00:27 61162597 >> /mnt/huge/rtemap_61 >> 3effe8000000-3effe9000000 rw-s 00000000 00:27 61162596 >> /mnt/huge/rtemap_60 >> 3effe9000000-3effea000000 rw-s 00000000 00:27 61162595 >> /mnt/huge/rtemap_59 >> 3effea000000-3effeb000000 rw-s 00000000 00:27 61162594 >> /mnt/huge/rtemap_58 >> 3effeb000000-3effec000000 rw-s 00000000 00:27 61162593 >> /mnt/huge/rtemap_57 >> 3effec000000-3effed000000 rw-s 00000000 00:27 61162592 >> /mnt/huge/rtemap_56 >> 3effed000000-3effee000000 rw-s 00000000 00:27 61162591 >> /mnt/huge/rtemap_55 >> 3effee000000-3effef000000 rw-s 00000000 00:27 61162590 >> /mnt/huge/rtemap_54 >> 3effef000000-3efff0000000 rw-s 00000000 00:27 61162589 >> /mnt/huge/rtemap_53 >> 3efff0000000-3efff1000000 rw-s 00000000 00:27 61162588 >> /mnt/huge/rtemap_52 >> 3efff1000000-3efff2000000 rw-s 00000000 00:27 61162565 >> /mnt/huge/rtemap_29 >> 3efff2000000-3efff3000000 rw-s 00000000 00:27 61162564 >> /mnt/huge/rtemap_28 >> 3efff3000000-3efff4000000 rw-s 00000000 00:27 61162563 >> /mnt/huge/rtemap_27 >> 3efff4000000-3efff5000000 rw-s 00000000 00:27 61162562 >> /mnt/huge/rtemap_26 >> 3efff5000000-3efff6000000 rw-s 00000000 00:27 61162561 >> /mnt/huge/rtemap_25 >> 3efff6000000-3efff7000000 rw-s 00000000 00:27 61162560 >> /mnt/huge/rtemap_24 >> 3efff7000000-3efff8000000 rw-s 00000000 00:27 61162559 >> /mnt/huge/rtemap_23 >> 3efff8000000-3efff9000000 rw-s 00000000 00:27 61162558 >> /mnt/huge/rtemap_22 >> 3efff9000000-3efffa000000 rw-s 00000000 00:27 61162557 >> /mnt/huge/rtemap_21 >> 3efffa000000-3efffb000000 rw-s 00000000 00:27 61162556 >> /mnt/huge/rtemap_20 >> 3efffb000000-3efffc000000 rw-s 00000000 00:27 61162555 >> /mnt/huge/rtemap_19 >> 3efffc000000-3efffd000000 rw-s 00000000 00:27 61162554 >> /mnt/huge/rtemap_18 >> 3efffd000000-3efffe000000 rw-s 00000000 00:27 61162553 >> /mnt/huge/rtemap_17 >> 3efffe000000-3effff000000 rw-s 00000000 00:27 61162552 >> /mnt/huge/rtemap_16 >> 3effff000000-3f0000000000 rw-s 00000000 00:27 61162551 >> /mnt/huge/rtemap_15 >> 3fffb7bc0000-3fffb7c10000 rw-p 00000000 00:00 0 >> 3fffb7c10000-3fffb7c50000 rw-s 00000000 00:12 3926240 /run/.rte_config >> 3fffb7c50000-3fffb7c70000 rw-p 00000000 00:00 0 >> 3fffb7c70000-3fffb7e20000 r-xp 00000000 08:32 7090531 >> /opt/at7.1/lib64/power8/libc-2.19.so >> 3fffb7e20000-3fffb7e30000 rw-p 001a0000 08:32 7090531 >> /opt/at7.1/lib64/power8/libc-2.19.so >> 3fffb7e30000-3fffb7e50000 rw-p 00000000 00:00 0 >> 3fffb7e50000-3fffb7e70000 r-xp 00000000 08:32 7090563 >> /opt/at7.1/lib64/power8/libpthread-2.19.so >> 3fffb7e70000-3fffb7e80000 rw-p 00010000 08:32 7090563 >> /opt/at7.1/lib64/power8/libpthread-2.19.so >> 3fffb7e80000-3fffb7e90000 r-xp 00000000 08:32 7090210 >> /opt/at7.1/lib64/libdl-2.19.so >> 3fffb7e90000-3fffb7ea0000 rw-p 00000000 08:32 7090210 >> /opt/at7.1/lib64/libdl-2.19.so >> 3fffb7ea0000-3fffb7ec0000 r-xp 00000000 08:32 7090533 >> /opt/at7.1/lib64/power8/libz.so.1.2.6 >> 3fffb7ec0000-3fffb7ed0000 rw-p 00010000 08:32 7090533 >> /opt/at7.1/lib64/power8/libz.so.1.2.6 >> 3fffb7ed0000-3fffb7f90000 r-xp 00000000 08:32 7090568 >> /opt/at7.1/lib64/power8/libm-2.19.so >> 3fffb7f90000-3fffb7fa0000 rw-p 000b0000 08:32 7090568 >> /opt/at7.1/lib64/power8/libm-2.19.so >> 3fffb7fa0000-3fffb7fc0000 r-xp 00000000 00:00 0 [vdso] >> 3fffb7fc0000-3fffb7ff0000 r-xp 00000000 08:32 7090048 >> /opt/at7.1/lib64/ld-2.19.so >> 3fffb7ff0000-3fffb8000000 rw-p 00020000 08:32 7090048 >> /opt/at7.1/lib64/ld-2.19.so >> 3ffffffd0000-400000000000 rw-p 00000000 00:00 0 [stack] >> >> >> -----Original Message----- >> From: Bruce Richardson [mailto:bruce.richardson@intel.com] >> Sent: 2016=E5=B9=B43=E6=9C=8823=E6=97=A5 1:11 >> To: Sergio Gonzalez Monroy >> Cc: Gowrishankar ; dev@dpdk.org; >> chaozhu@linux.vnet.ibm.com; David Marchand >> Subject: Re: [dpdk-dev] [PATCH] eal/ppc: fix secondary process to map >> hugepages in correct order >> >> On Tue, Mar 22, 2016 at 04:35:32PM +0000, Sergio Gonzalez Monroy wrote= : >>> First of all, forgive my ignorance regarding ppc64 and if the >>> questions are naive but after having a look to the already existing >>> code for ppc64 and this patch now, why are we doing this reverse >>> mapping at all? >>> >>> I guess the question revolves around the comment in eal_memory.c: >>> 1316 /* On PPC64 architecture, the mmap always start = from >>> higher >>> 1317 * virtual address to lower address. Here, both = the >>> physical >>> 1318 * address and virtual address are in descending >> order >>> */ >>> >>> From looking at the code, for ppc64 we do qsort in reverse order an= d >>> thereafter everything looks to be is done to account for that reverse >>> sorting. >>> >>> CC: Chao Zhu and David Marchand as original author and reviewer of >>> the >> code. >>> Sergio >>> >> Just to add my 2c here. At one point, with I believe some i686 >> installs - don't remember the specific OS/kernel, we found that the >> mmap calls were returning the highest free address first and then >> working downwards - must like seems to be described here. To fix this >> we changed the mmap code from assuming that addresses are mapped >> upwards, to instead explicitly requesting a large free block of memory >> (mmap of /dev/zero) to find a free address space range of the correct >> size, and then explicitly mmapping each individual page to the >> appropriate place in that free range. With this scheme it didn't >> matter whether the OS tried to mmap the pages from the highest or >> lowest address because we always told the OS where to put the page (an= d we knew the slot was free from the earlier block mmap). >> Would this scheme not also work for PPC in a similar way? (Again, >> forgive unfamiliarity with PPC! :-) ) >> >> /Bruce >> >>> On 07/03/2016 14:13, Gowrishankar wrote: >>>> From: Gowri Shankar >>>> >>>> For a secondary process address space to map hugepages from every >>>> segment of primary process, hugepage_file entries has to be mapped >>>> reversely from the list that primary process updated for every >>>> segment. This is for a reason that, in ppc64, hugepages are sorted >>>> for >> decrementing addresses. >>>> Signed-off-by: Gowrishankar >>>> --- >