From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753421AbcITCpV (ORCPT ); Mon, 19 Sep 2016 22:45:21 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57865 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbcITCpT (ORCPT ); Mon, 19 Sep 2016 22:45:19 -0400 From: "Aneesh Kumar K.V" To: christophe leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Scott Wood Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 2/3] powerpc: get hugetlbpage handling more generic In-Reply-To: <2c8682d7-78ce-0aaf-79bd-85a85849e227@c-s.fr> References: <87poo0xx13.fsf@linux.vnet.ibm.com> <2c8682d7-78ce-0aaf-79bd-85a85849e227@c-s.fr> Date: Tue, 20 Sep 2016 08:15:09 +0530 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16092002-0008-0000-0000-0000059D920E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005788; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000185; SDB=6.00759330; UDB=6.00360905; IPR=6.00533596; BA=6.00004736; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012721; XFM=3.00000011; UTC=2016-09-20 02:45:16 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16092002-0009-0000-0000-00003B6E901E Message-Id: <874m5bxpai.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-19_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609200035 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org christophe leroy writes: >> >> >>> for (psize = 0; psize < MMU_PAGE_COUNT; ++psize) { >>> unsigned shift; >>> unsigned pdshift; >>> @@ -860,16 +807,31 @@ static int __init hugetlbpage_init(void) >>> * if we have pdshift and shift value same, we don't >>> * use pgt cache for hugepd. >>> */ >>> - if (pdshift != shift) { >>> + if (pdshift > shift) { >>> pgtable_cache_add(pdshift - shift, NULL); >>> if (!PGT_CACHE(pdshift - shift)) >>> panic("hugetlbpage_init(): could not create " >>> "pgtable cache for %d bit pagesize\n", shift); >>> + } else if (!hugepte_cache) { >>> + /* >>> + * Create a kmem cache for hugeptes. The bottom bits in >>> + * the pte have size information encoded in them, so >>> + * align them to allow this >>> + */ >>> + hugepte_cache = kmem_cache_create("hugepte-cache", >>> + sizeof(pte_t), >>> + HUGEPD_SHIFT_MASK + 1, >>> + 0, NULL); >>> + if (hugepte_cache == NULL) >>> + panic("%s: Unable to create kmem cache " >>> + "for hugeptes\n", __func__); >>> + >> >> >> We don't need hugepte_cache for book3s 64K. I guess we will endup >> creating one here ? > > Should not, because on book3s 64k, we will have pdshift > shift > won't we ? > on 64k book3s, we have pdshift == shift and we don't need to create hugepd cache on book3s 64k. -aneesh