Skip to contentSkip to conversation

pagewalk API

DISCUSSION Matthew Wilcox 3 participants 3 messages Jan 4, 2016 – Jan 5, 2016 Memory management

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 13 lines · 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.

Quoted 6 lines

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

Quoted 6 lines

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

Signature · 7 lines
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#2 lore raw

Hi Kirill, Matthew,

Quoted 10 lines · Kirill A. Shutemov
Quoted 9 lines · 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.

Quoted 5 lines
Quoted 5 lines

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.

Quoted 4 lines
Quoted 4 lines

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.

Quoted 3 lines

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