[PATCH -V10 00/15] THP support for PPC64

[Aneesh Kumar K.V]

Benjamin Herrenschmidt <benh at kernel.crashing.org> writes:

> On Wed, 2013-06-19 at 00:16 +0530, Aneesh Kumar K.V wrote:
>
>> But will that by anonymous memory ? ie, will we find them suitable for
>> THP allocation ?
>
> The 4k pages themselves with 4k_PFN no, but the segment yes. A single of
> these will demote the whole segment, ie 256M or 1T.
>
>> >   * If you find a THP in hash_page and the segment size is 4k, fault
>> >
>> >   * In do_page_fault, re-check for that condition (or maybe we can make
>> > hash_page return a specific bit that gets ORed into the error_code into
>> > do_page_fault ?) and split huge pages there.
>> >
>> > But that's just an idea off the top of my mind, there might be a better
>> > way. Of course this needs to be tested.
>> >
>> > BTW. For the subpage protection, similarily, you need to make sure you
>> > properly map the entire segment as "no THP", not just the range
>> > passed-in by the user.
>> 
>> Can you explain that more, why should the entire segment be marked no THP ?
>> The segment can work with 4K base page size and we still be able to
>> allocate a hugepage in that segment.
>
> Will we be able to track all the possible hashings of the huge page on a
> 4k segment ?

Yes. The comment above hpte_valid explains that 

 * The linux hugepage PMD now include the pmd entries followed by the address
 * to the stashed pgtable_t. The stashed pgtable_t contains the hpte bits.
 * [ 1 bit secondary | 3 bit hidx | 1 bit valid | 000]. We use one byte per
 * each HPTE entry. With 16MB hugepage and 64K HPTE we need 256 entries and
 * with 4K HPTE we need 4096 entries. Both will fit in a 4K pgtable_t.


-aneesh