From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) by dpdk.org (Postfix) with ESMTP id 009FAA2F for ; Wed, 15 Feb 2017 09:51:59 +0100 (CET) Received: by mail-wr0-f177.google.com with SMTP id c4so28186177wrd.2 for ; Wed, 15 Feb 2017 00:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=PFoVzmTCM6lohGHwIC9WP5aDLeiNWLRnVRPoYYF8enc=; b=MvMYbbh9wW20v7Twa3Gm0AhfsZ5bLFVlz5xHq3g6hgz1dfp5uB9zT2SDd196hR5xPb t6n5cga30vDdSUwUrZdEGLHZ1S5sxKhh8UHsDNyU6YlPvWQG0Y6KGtp4IhfNDDuTEo14 OvNtD4Bowsod9vrkQ2BdYPUEr+ClRBwrVCe/+W8dv86P5Hi72XobLYFTcu0XIE1PIkun 1sMw0/P1flG9PFjPGDGKcPfO+it6DmF9jL/Oge9Du9kwC7eCpfIDAk5i7z6YobF5M0m2 5+lqogSQKIYg7fxP5lnAd9rsbWhXVttdKEH7qKQvriaqr6xIC+ATXu/QdRlsfYGd9p01 TZAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=PFoVzmTCM6lohGHwIC9WP5aDLeiNWLRnVRPoYYF8enc=; b=pDDJZFCUA+D0O6Acy2bmItySqcMhXgTzc7iqaRYuzWlmh+ehs6dkC6gBV1r73O29+y bDc/7FKiPdl/K2xHn4o+daGwt68dW/T9am8indB/43ZNauRPA3vvZpHJ+JIstiUABcFB U9FFdO8D9yREKqHdpXkpvVjHt8T52fGF4Eo+E506avht9gwyLHuv2lXoGpMwL3+Bndkv kca8YlJmumlrA9yu1JbKzLVc4s+OpIzMZzG4feEKhZgmzH/jNkJRp71EvPFCNT/aqxci Z6PpWGng5cIT/MCu4ovn3jN8K50DaoQnUwyHnSG/5PmYfyXdR8RxEiLg1kk5o2ZlyPs5 H5xQ== X-Gm-Message-State: AMke39kCqQkC+vsCQSncCbgNotZWXQYe0j4xYx9nV+VJu8S2RyhmQxvuFOoaqcrSZEULe5S+ X-Received: by 10.223.134.173 with SMTP id 42mr32795502wrx.95.1487148719575; Wed, 15 Feb 2017 00:51:59 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 202sm4454445wmp.20.2017.02.15.00.51.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 00:51:58 -0800 (PST) From: Thomas Monjalon To: Sergio Gonzalez Monroy , Chao Zhu , 'Gowrishankar' Cc: dev@dpdk.org, 'Bruce Richardson' , 'David Marchand' Date: Wed, 15 Feb 2017 09:51:58 +0100 Message-ID: <18368492.qbb3ovVQo8@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <78ee10ce-9e41-6019-533c-ef0677ce337e@intel.com> References: <1457360003-30055-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <000601d1b273$8e261a60$aa724f20$@linux.vnet.ibm.com> <78ee10ce-9e41-6019-533c-ef0677ce337e@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Subject: Re: [dpdk-dev] [PATCH] eal/ppc: fix secondary process to map hugepages in correct order 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: Wed, 15 Feb 2017 08:52:00 -0000 There was no follow-up on this discussion. Please, what is the conclusion? 2016-05-20 11:25, Sergio Gonzalez Monroy: > On 20/05/2016 09:41, Chao Zhu wrote: > > Sergio, > > > > The step 4 will not fail because each huge page will get an virtual= address finally, though it's a different address. If you take a look a= t 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 wan= t to say is, this bug also influence the secondary process in function = rte_eal_hugepage_attach(). It can make the secondary process fail to in= it. I'm trying to figure out how to make it work. >=20 > You are right, I misread the code. >=20 > So basically because mmap ignores the hint to mmap on the requested a= ddress, > by default we get VA maps in decreasing address order. >=20 > Knowing that, PPC orders pages by decreasing physical address order s= o when > this happens we actually get hugepages in order in the "new" final_va= . >=20 > Not sure if that makes sense but I think I understand where you are=20= > coming from. >=20 > I think we need to document this as know issue and/or add comments re= garding > this behavior , basically calling out that all this "reverse-ordering= "=20 > is required > because mmap fails to map on the requested VA. >=20 > Thanks, > Sergio >=20 > > -----Original Message----- > > From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy@intel.c= om] > > Sent: 2016=E5=B9=B45=E6=9C=8820=E6=97=A5 16:01 > > To: Chao Zhu ; 'Bruce Richardson' > > Cc: 'Gowrishankar' ; dev@dpdk.or= g; 'David Marchand' > > Subject: Re: [dpdk-dev] [PATCH] eal/ppc: fix secondary process to m= ap hugepages in correct order > > > > On 20/05/2016 04:03, Chao Zhu wrote: > >> Bruce, > >> > >> Recently, we find some bugs with mmap in PowerLinux. The mmap does= n't > >> respect the address hints. In function get_virtual_area() in > >> eal_memory.c, mmap get the free virtual address range as the addre= ss > >> hint. However, when mapping the real memory in > >> rte_eal_hugepage_init(), mmap doesn't return the same address as t= he > >> requested address. When taking a look at the /proc//maps, the= > >> requested address range is free for use. With this bug, pre-alloca= te some free space doesn't work. > > Hi Chao, > > > > If I understand you correctly, the issue you are describing would c= ause DPDK to fail initialization even with the reverse reordering that = you are 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 addr= ess 4. map_all_hugepages(..., orig=3D0) > > - Now we try to get big chunk of virtual address for a block = of contig hugepages > > so we know we have that virtual address chunk available. > > - Then we try to remap each page of that block of contig page= s into that > > virtual address chunk. > > > > So the issue you are describing would make step 4 fail regardless o= f the 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 ke= rnel > >> 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_co= nfig > >> 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 w= rote: > >>> First of all, forgive my ignorance regarding ppc64 and if the > >>> questions are naive but after having a look to the already existi= ng > >>> 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 st= art from > >>> higher > >>> 1317 * virtual address to lower address. Here, b= oth the > >>> physical > >>> 1318 * address and virtual address are in descen= ding > >> order > >>> */ > >>> > >>> From looking at the code, for ppc64 we do qsort in reverse orde= r and > >>> thereafter everything looks to be is done to account for that rev= erse > >>> sorting. > >>> > >>> CC: Chao Zhu and David Marchand as original author and reviewer o= f > >>> 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 th= e > >> mmap calls were returning the highest free address first and then > >> working downwards - must like seems to be described here. To fix t= his > >> we changed the mmap code from assuming that addresses are mapped > >> upwards, to instead explicitly requesting a large free block of me= mory > >> (mmap of /dev/zero) to find a free address space range of the corr= ect > >> 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= (and 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 ever= y > >>>> segment of primary process, hugepage_file entries has to be mapp= ed > >>>> reversely from the list that primary process updated for every > >>>> segment. This is for a reason that, in ppc64, hugepages are sort= ed > >>>> for > >> decrementing addresses. > >>>> Signed-off-by: Gowrishankar > >>>> --- > > >=20