Re: pagewalk API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Kirill, Matthew,

On Mon, Jan 04, 2016 at 10:47:27PM +0200, Kirill A. Shutemov wrote:
> On Mon, Jan 04, 2016 at 01:29:39PM -0500, Matthew Wilcox wrote:
> > 
> > I find myself in the position of needing to expand the pagewalk API to
> > allow PUDs to be passed to pagewalk handlers.
> > 
> > The problem with the current pagewalk API is that it requires the callers
> > to implement a lot of boilerplate, and the further up the hierarchy we
> > intercept the pagewalk, the more boilerplate has to be implemented in each
> > caller, to the point where it's not worth using the pagewalk API any more.
> >
> > Compare and contrast mincore's pud_entry that only has to handle PUDs
> > which are guaranteed to be (1) present, (2) huge, (3) locked versus the
> > PMD code which has to take care of checking all three things itself.
> > 
> > (http://marc.info/?l=linux-mm&m=145097405229181&w=2)

In the current pagewalk API, each walk can choose whether to enter lower
levels with return values of callbacks, so I think that using ->pud_entry
along with ->pmd_entry or ->pte_entry is a valid usage.

The confusion seems to be in the current code (not in your patch.) Currently
many of current ->pmd_entry()s handle both PMD stuff and PTE stuff, but ideally,
each level of callback should deal with only the relevant level of entry to
minimize duplicate code.
I tried it a few years ago, but that's unfinished at that time because there
was a difference in ptl pattern among pagewalk callers.

> > Kirill's point is that it's confusing to have the PMD and PUD handling
> > be different, and I agree.  But it certainly saves a lot of code in the
> > callers.  So should we convert the PMD code to be similar?  Or put a
> > subptimal API in for the PUD case?

.. so I like "converting PMD code" option.

> Naoya, if I remember correctly, we had something like this on early stage
> of you pagewalk rework. Is it correct? If yes, why it was changed to what
> we have now?

Yes, maybe I mentioned the suboptimality in current code. My pagewalk work
didn't solve it because main focus was on fixing problems around ->hugetlb_entry.
So this might be a good time to revisit the issue.

Thanks,
Naoya Horiguchi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]