From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (bilbo.ozlabs.org [103.22.144.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yNWHj6JR7zDqjm for ; Fri, 27 Oct 2017 15:34:41 +1100 (AEDT) Date: Fri, 27 Oct 2017 15:34:30 +1100 From: Paul Mackerras To: "Aneesh Kumar K.V" Cc: benh@kernel.crashing.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 00/16] Remove hash page table slot tracking from linux PTE Message-ID: <20171027043430.GA27483@fergus.ozlabs.ibm.com> References: <20171027040833.3644-1-aneesh.kumar@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20171027040833.3644-1-aneesh.kumar@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Oct 27, 2017 at 09:38:17AM +0530, Aneesh Kumar K.V wrote: > Hi, > > With hash translation mode we always tracked the hash pte slot details in linux page table. > This occupied space in the linux page table and also limitted our ability to support > linux features that require additional PTE bits. This series attempt to lift this > limitation by not tracking slot number in linux page table. We still track slot details > w.r.t Transparent Hugepage entries because an invalidate there requires us to go through > all the 256 hash pte slots. So tracking whether hash page table entry is valid helps us in > avoiding a lot of hcalls there. With THP entries we don't keep slot details in the primary > linux page table entry but in the second half of page table. Hence tracking slot details > for THP doesn't take up space in PTE. > > Even though we don't track slot, for removing/updating hash page table entry, PAPR hcalls expect > hash page table slot details. On pseries we find slot using H_READ hcall using H_READ_4 flags. > This implies an additional 2 hcalls in the updatepp and remove paths. The patch series also > attempt to limit the impact of this by adding new hcalls that does remove/update of hash page table > entry using hash value instead of hash page table slot. > > Below is the performance numbers observed when running a workload that does the below sequence > > for(5000) { > mmap(128M) > touch every page of 2048 page > munmap() > } > > The test is run with address randomization off, swap disabled in both host and guest. > > > |------------+----------+---------------+--------------------------+-----------------------| > | iterations | platform | without patch | With series and no hcall | With series and hcall | > |------------+----------+---------------+--------------------------+-----------------------| > | 1 | powernv | | 50.818343 | | > | 2 | powernv | | 50.744123 | | > | 3 | powernv | | 50.721603 | | > | 4 | powernv | | 50.739922 | | > | 5 | powernv | | 50.638555 | | > | 1 | powernv | 51.388249 | | | > | 2 | powernv | 51.789701 | | | > | 3 | powernv | 52.240394 | | | > | 4 | powernv | 51.432255 | | | > | 5 | powernv | 51.392947 | | | > |------------+----------+---------------+--------------------------+-----------------------| > | 1 | pseries | | | 123.154394 | > | 2 | pseries | | | 122.253956 | > | 3 | pseries | | | 117.666344 | > | 4 | pseries | | | 117.681479 | > | 5 | pseries | | | 117.735808 | > | 1 | pseries | | 119.424940 | | > | 2 | pseries | | 117.663078 | | > | 3 | pseries | | 118.345584 | | > | 4 | pseries | | 119.620934 | | > | 5 | pseries | | 119.463185 | | > | 1 | pseries | 122.810867 | | | > | 2 | pseries | 115.760801 | | | > | 3 | pseries | 115.257030 | | | > | 4 | pseries | 116.617884 | | | > | 5 | pseries | 117.247036 | | | > |------------+----------+---------------+--------------------------+-----------------------| > How do we interpret these numbers? Are they times, or speed? Is larger better or worse? Can you give us the mean and standard deviation for each set of 5 please? Paul.