[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180507122346.GE18116@bombadil.infradead.org>
Date: Mon, 7 May 2018 05:23:46 -0700
From: Matthew Wilcox <willy@...radead.org>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Andy Lutomirski <luto@...capital.net>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
X86 ML <x86@...nel.org>, Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Proof-of-concept: better(?) page-table manipulation API
On Mon, May 07, 2018 at 02:31:25PM +0300, Kirill A. Shutemov wrote:
> > Also, what does lvl == 0 mean? Is it the top or the bottom? I think a
> > comment would be helpful.
>
> It is bottom. But it should be up to architecture to decide.
That's not true because ...
> > > +static inline void ptp_walk(ptp_t *ptp, unsigned long addr)
> > > +{
> > > + ptp->ptr = (unsigned long *)ptp_page_vaddr(ptp);
> > > + ptp->ptr += __pt_index(addr, --ptp->lvl);
> > > +}
> >
> > Can you add a comment that says what this function does?
>
> Okay, I will.
>
> > Why does it not change the level?
>
> It does. --ptp->lvl.
... you've hardcoded that walking down decrements the level by 1.
I don't see that as a defect; it's just part of the API that needs
documenting.
Powered by blists - more mailing lists