[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240326150118.GI6245@nvidia.com>
Date: Tue, 26 Mar 2024 12:01:18 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Peter Xu <peterx@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [RFC PATCH 1/8] mm: Provide pagesize to pmd_populate()
On Mon, Mar 25, 2024 at 07:05:01PM +0000, Christophe Leroy wrote:
> Not looked into details yet, but I guess so.
>
> By the way there is a wiki dedicated to huge pages on powerpc, you can
> have a look at it here :
> https://github.com/linuxppc/wiki/wiki/Huge-pages , maybe you'll find
> good ideas there to help me.
There sure are alot of page tables types here
I'm a bit wondering about terminology, eg on the first diagram "huge
pte entry" means a PUD entry that is a leaf? Which ones are contiguous
replications?
Just general remarks on the ones with huge pages:
hash 64k and hugepage 16M/16G
radix 64k/radix hugepage 2M/1G
radix 4k/radix hugepage 2M/1G
nohash 32
- I think this is just a normal x86 like scheme? PMD/PUD can be a
leaf with the same size as a next level table.
Do any of these cases need to know the higher level to parse the
lower? eg is there a 2M bit in the PUD indicating that the PMD
is a table of 2M leafs or does each PMD entry have a bit
indicating it is a leaf?
hash 4k and hugepage 16M/16G
nohash 64
- How does this work? I guess since 8xx explicitly calls out
consecutive this is actually the pgd can point to 512 256M
entries or 8 16G entries? Ie the table size at each level is
varable? Or is it the same and the table size is still 512 and
each 16G entry is replicated 64 times?
Do the offset accessors already abstract this enough?
8xx 4K
8xx 16K
- As this series does?
Jason
Powered by blists - more mailing lists