[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56E10738.7020204@linux.vnet.ibm.com>
Date: Thu, 10 Mar 2016 11:03:44 +0530
From: Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org
CC: hughd@...gle.com, kirill@...temov.name, n-horiguchi@...jp.nec.com,
mgorman@...hsingularity.net, akpm@...ux-foundation.org
Subject: Re: [RFC 4/9] powerpc/mm: Split huge_pte_alloc function for BOOK3S
64K
On 03/10/2016 01:25 AM, Aneesh Kumar K.V wrote:
> Anshuman Khandual <khandual@...ux.vnet.ibm.com> writes:
>
>> > [ text/plain ]
>> > From: root <root@...alpine2-lp8.aus.stglabs.ibm.com>
>> >
>> > Currently the 'huge_pte_alloc' function has two versions, one for the
>> > BOOK3S and the other one for the BOOK3E platforms. This change splits
>> > the BOOK3S version into two parts, one for the 4K page size based
>> > implementation and the other one for the 64K page sized implementation.
>> > This change is one of the prerequisites towards enabling GENERAL_HUGETLB
>> > implementation for BOOK3S 64K based huge pages.
> I really wish we reduce #ifdefs in C code and start splitting hash
> and nonhash code out where ever we can.
Okay but here we are only dealing with 64K and 4K configs inside book3s.
I guess it covers both hash and no hash implementations. Not sure if I
got it correctly.
>
> What we really want here is a book3s version and in book3s version use
> powerpc specific huge_pte_alloc only if GENERAL_HUGETLB was not defined.
got it.
> Don't limit it to 64k linux page size. We should select between powerpc
> specific implementation and generic code using GENERAL_HUGETLB define.
Got it. will try.
Powered by blists - more mailing lists