Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751055AbcKYIPp (ORCPT ); Fri, 25 Nov 2016 03:15:45 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:13208 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750771AbcKYIPm (ORCPT ); Fri, 25 Nov 2016 03:15:42 -0500 Subject: Re: [v3,2/3] powerpc: get hugetlbpage handling more generic To: Scott Wood References: <69b1226ce134761fd7ab81a498bdb85cd737280f.1474441302.git.christophe.leroy@c-s.fr> <20161124052330.GA17212@home.buserror.net> Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org From: Christophe LEROY Message-ID: Date: Fri, 25 Nov 2016 09:14:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161124052330.GA17212@home.buserror.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1909 Lines: 42 Le 24/11/2016 ? 06:23, Scott Wood a ?crit : > On Wed, Sep 21, 2016 at 10:11:54AM +0200, Christophe Leroy wrote: >> Today there are two implementations of hugetlbpages which are managed >> by exclusive #ifdefs: >> * FSL_BOOKE: several directory entries points to the same single hugepage >> * BOOK3S: one upper level directory entry points to a table of hugepages >> >> In preparation of implementation of hugepage support on the 8xx, we >> need a mix of the two above solutions, because the 8xx needs both cases >> depending on the size of pages: >> * In 4k page size mode, each PGD entry covers a 4M bytes area. It means >> that 2 PGD entries will be necessary to cover an 8M hugepage while a >> single PGD entry will cover 8x 512k hugepages. >> * In 16 page size mode, each PGD entry covers a 64M bytes area. It means >> that 8x 8M hugepages will be covered by one PGD entry and 64x 512k >> hugepages will be covers by one PGD entry. >> >> This patch: >> * removes #ifdefs in favor of if/else based on the range sizes >> * merges the two huge_pte_alloc() functions as they are pretty similar >> * merges the two hugetlbpage_init() functions as they are pretty similar >> >> Signed-off-by: Christophe Leroy >> Reviewed-by: Aneesh Kumar K.V > > With this patch on e6500, running the hugetlb testsuite results in the > system hanging in a storm of OOM killer invocations (I'll try to debug > more deeply later). This patch also changes the default hugepage size on > FSL book3e from 4M to 16M. > Regarding the default hugepage size, it is a result of the merge of the two hugetlbpage_init(). Should I add an ifdef to get 4M on FSL book3e by default ? What's the reason for selecting different hugepage sizes depending on the CPU ? I thought default size was selected based on what was existing. What testsuite do you run exactly ? Christophe