Re: [PATCH 04/19] LoongArch: Add common headers

[Huacai Chen <chenhuacai@gmail.com>]

Hi, Arnd,

On Wed, Aug 18, 2021 at 5:38 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Aug 16, 2021 at 6:10 AM Huacai Chen <chenhuacai@gmail.com> wrote:
> > On Sun, Aug 15, 2021 at 4:56 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> > > > #ifdef CONFIG_PAGE_SIZE_16KB
> > > > #define PGD_ORDER               0
> > > > #define PUD_ORDER               aieeee_attempt_to_allocate_pud
> > > > #define PMD_ORDER               0
> > > > #define PTE_ORDER               0
> > > > #endif
> > >
> > > This doesn't seem to make sense at all however: it looks like you have
> > > three levels of 16KB page tables, so you get 47 bits, not 40. This
> > > means you waste 99% of the available address space when you
> > > run this kernel on a CPU that is able to access the entire space.
> > Emm, this "waste" seems harmless. :)
>
> It's not actively harmful, just silly to offer the 4/11/11/14 option that is
> never the ideal choice given the alternatives of
>
> * 11/11/11/14: normal 16K 3level, but up to 47 bits if supported by CPU
> * 11/11/14: 16K 2level, just dropping the top level for 36-bit TASK_SIZE
> * 13/13/14: 16K 2level, fewer levels with larger PGD/PMD
> * 10/9/9/12: normal 4K 3level, same # of levels, better memory usage
>
> > > > #ifdef CONFIG_PAGE_SIZE_64KB
> > > > #define PGD_ORDER               0
> > > > #define PUD_ORDER               aieeee_attempt_to_allocate_pud
> > > > #define PMD_ORDER               0
> > > > #define PTE_ORDER               0
> > > > #endif
> > > > #endif
> > >
> > > I suppose you can't ever have more than 48 bits? Otherwise this option
> > > would give you 55 bits of address space.
> >
> > We will have 56bits CPU in future, and then we will add a VA_BITS_56 config.
>
> Right, so same as above: why not make this VA_BITS_55 already and fall
> back to 40 or 48 bits on current CPUs
>
> > > > Since 40 and 48 is the most popular VABITS of LoongArch hardware, and
> > > > LoongArch has a software-managed TLB, it seems "define page table
> > > > layout depends on kernel VABITS" is more natural for LoongArch.
> > >
> > > How common are Loongarch64 CPUs that limit the virtual address space
> > > to 40 bits instead of the full 48 bits? What is the purpose of limiting the
> > > CPU this way?
> > We have some low-end 64bits CPU whose VA is 40bits, this can reduce
> > the internal address bus width, so save some hardware cost and
> > complexity.
>
> Ok. So I could understand making CONFIG_VA_BITS_40 hardcode the
> VA size at compile time, but if you always support the fallback to any
> size at runtime, just allow using the high addresses.
Define a larger VA_BITS and fallback to a smaller one (TASKSIZE64) if
hardware doesn't support it? If so, there will be a problem: we should
define a 4-level page table, but the fallback only needs a 2-level or
3-level page table.

Huacai
>
>        Arnd