From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 26 Jan 2018 10:30:07 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: Dave Hansen , Konstantin Khlebnikov , X86 ML , Borislav Petkov , Neil Berrington , LKML , stable , "Kirill A. Shutemov" Subject: Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems Message-ID: <20180126093006.n55q4dkkrexymsji@gmail.com> References: <346541c56caed61abbe693d7d2742b4a380c5001.1516914529.git.luto@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: * Andy Lutomirski 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