On 11/19/2014 02:00 PM, Kirill A. Shutemov wrote: > On Wed, Nov 19, 2014 at 11:51:09AM +0100, Jerome Marchand wrote: >> On 11/05/2014 03:49 PM, Kirill A. Shutemov wrote: >>> We're going to allow mapping of individual 4k pages of THP compound and >>> we need a cheap way to find out how many time the compound page is >>> mapped with PMD -- compound_mapcount() does this. >>> >>> page_mapcount() counts both: PTE and PMD mappings of the page. >>> >>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> >>> --- >>> include/linux/mm.h | 17 +++++++++++++++-- >>> include/linux/rmap.h | 4 ++-- >>> mm/huge_memory.c | 23 ++++++++++++++--------- >>> mm/hugetlb.c | 4 ++-- >>> mm/memory.c | 2 +- >>> mm/migrate.c | 2 +- >>> mm/page_alloc.c | 13 ++++++++++--- >>> mm/rmap.c | 50 +++++++++++++++++++++++++++++++++++++++++++------- >>> 8 files changed, 88 insertions(+), 27 deletions(-) >>> >>> diff --git a/include/linux/mm.h b/include/linux/mm.h >>> index 1825c468f158..aef03acff228 100644 >>> --- a/include/linux/mm.h >>> +++ b/include/linux/mm.h >>> @@ -435,6 +435,19 @@ static inline struct page *compound_head(struct page *page) >>> return page; >>> } >>> >>> +static inline atomic_t *compound_mapcount_ptr(struct page *page) >>> +{ >>> + return (atomic_t *)&page[1].mapping; >>> +} >> >> IIUC your patch overloads the unused mapping field of the first tail >> page to store the PMD mapcount. That's a non obvious trick. Why not make >> it more explicit by adding a new field (say compound_mapcount - and the >> appropriate comment of course) to the union to which mapping already belong? > > I don't think we want to bloat struct page description: nobody outside of > helpers should use it direcly. And it's exactly what we did to store > compound page destructor and compound page order. Yes, but hiding it might make people think this field is unused when it's not. If it has been done that way for a while, maybe it's not as much trouble as I think it is, but could you at least add a comment in the helper. > >> The patch description would benefit from more explanation too. > > Agreed. >
Attachment:
signature.asc
Description: OpenPGP digital signature