From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id A0D88B70B1 for ; Sat, 16 Jun 2012 00:43:13 +1000 (EST) Received: by pbbrp16 with SMTP id rp16so6083273pbb.38 for ; Fri, 15 Jun 2012 07:43:11 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 15 Jun 2012 16:43:06 +0200 Message-ID: Subject: Questions on Hugetlb for bookE and PHYS_64BIT From: telenn barz To: linuxppc-dev@lists.ozlabs.org Content-Type: multipart/alternative; boundary=047d7b2ee08d9ae20304c283d5e1 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --047d7b2ee08d9ae20304c283d5e1 Content-Type: text/plain; charset=ISO-8859-1 Hi all, CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit physical addresses. Is it this configuration option we have to enable for the support of 36-bit real memory (as are capable the Freescale e500v2 or e500mc cores family) ? The Hugetlb patch for BookE ( https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-June/091315.html) seems to be surbordinated to CONFIG_PHYS_64BIT. Is there any good reason why it is not supported when CONFIG_PHYS_64BIT is disabled ? Thanks, Telenn --047d7b2ee08d9ae20304c283d5e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

CONFIG_PHYS_64BIT enables kernel support for larger than 32-= bit physical addresses. Is it this configuration option we have to enable f= or the support of 36-bit real memory (as are capable the Freescale e500v2 o= r e500mc cores family) ?

The Hugetlb patch for BookE (https://lists.ozlabs.org/pipermail/= linuxppc-dev/2011-June/091315.html) seems to be surbordinated to CONFIG= _PHYS_64BIT. Is there any good reason why it is not supported when CONFIG_P= HYS_64BIT is disabled ?

Thanks,
Telenn
--047d7b2ee08d9ae20304c283d5e1-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 81FC4B7095 for ; Sat, 16 Jun 2012 04:12:09 +1000 (EST) Message-ID: <4FDB7AEC.2010102@freescale.com> Date: Fri, 15 Jun 2012 13:11:56 -0500 From: Scott Wood MIME-Version: 1.0 To: telenn barz Subject: Re: Questions on Hugetlb for bookE and PHYS_64BIT References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Cc: linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/15/2012 09:43 AM, telenn barz wrote: > Hi all, > > CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit physical > addresses. Is it this configuration option we have to enable for the > support of 36-bit real memory (as are capable the Freescale e500v2 or > e500mc cores family) ? Yes. > The Hugetlb patch for BookE > (https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-June/091315.html) > seems to be surbordinated to CONFIG_PHYS_64BIT. Is there any good reason > why it is not supported when CONFIG_PHYS_64BIT is disabled ? Because it would be extra work to support that configuration, and nobody's felt enough of a need for it to put in that work. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B89D8B72D1 for ; Tue, 19 Jun 2012 00:23:14 +1000 (EST) Subject: Re: Questions on Hugetlb for bookE and PHYS_64BIT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Becky Bruce In-Reply-To: <4FDB7AEC.2010102@freescale.com> Date: Mon, 18 Jun 2012 09:22:59 -0500 Message-Id: <539824A8-EBAE-44AA-9818-9D4462F25DE2@kernel.crashing.org> References: <4FDB7AEC.2010102@freescale.com> To: Scott Wood Cc: telenn barz , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Jun 15, 2012, at 1:11 PM, Scott Wood wrote: > On 06/15/2012 09:43 AM, telenn barz wrote: >> Hi all, >>=20 >> CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit = physical >> addresses. Is it this configuration option we have to enable for the >> support of 36-bit real memory (as are capable the Freescale e500v2 or >> e500mc cores family) ? >=20 > Yes. >=20 >> The Hugetlb patch for BookE >> = (https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-June/091315.html) >> seems to be surbordinated to CONFIG_PHYS_64BIT. Is there any good = reason >> why it is not supported when CONFIG_PHYS_64BIT is disabled ? >=20 > Because it would be extra work to support that configuration, and > nobody's felt enough of a need for it to put in that work. Most of the use-cases we had demanding hugetlb were *also* cases that = had large amounts of memory, so this is the model we adopted. Plus, we = need some of the code from the 36-bit implementation, including the part = that causes the lowest level of the page table to widen to 64 bits; = additionally we did not measure much, if any, of a perf hit when = enabling PHYS_64BIT.=20 Obviously, it could be made to work without it, although there are real = code changes required. But unless you have a case where you have a = noticeable performance drop from enabling CONFIG_PHYS_64BIT, it's not = worth the effort. -Becky >=20 > -Scott >=20 > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev