pagewalk API

pagewalk API

[Matthew Wilcox]

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)

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?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: pagewalk API

[Kirill A. Shutemov]

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)
> 
> 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?

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?

> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: pagewalk API

[Naoya Horiguchi]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>