[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180126093006.n55q4dkkrexymsji@gmail.com>
Date: Fri, 26 Jan 2018 10:30:07 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: Dave Hansen <dave.hansen@...el.com>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
Neil Berrington <neil.berrington@...acore.com>,
LKML <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on
very-large-memory 4-level systems
* Andy Lutomirski <luto@...nel.org> wrote:
> What I'd really like to see is an entirely different API. Maybe:
>
> typedef struct {
> opaque, but probably includes:
> int depth; /* 0 is root */
> void *table;
> } ptbl_ptr;
>
> ptbl_ptr root_table = mm_root_ptbl(mm);
>
> set_ptbl_entry(root_table, pa, prot);
>
> /* walk tables */
> ptbl_ptr pt = ...;
> ptentry_ptr entry;
> while (ptbl_has_children(pt)) {
> pt = pt_next(pt, addr);
> }
> entry = pt_entry_at(pt, addr);
> /* do something with entry */
>
> etc.
>
> Now someone can add a sixth level without changing every code path in
> the kernel that touches page tables.
Iteration based page table lookups would be neat.
A sixth level is unavoidable on x86-64 I think - we'll get there in a decade or
so? The sixth level will also use up the last ~8 bits of virtual memory available
on 64-bit.
Thanks,
Ingo
Powered by blists - more mailing lists