Re: [PATCHv9 26/36] mm: rework mapcount accounting to enable 4k mapping of THPs

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

 



On Fri, Jul 31, 2015 at 05:04:18PM +0200, Jerome Marchand wrote:
> On 07/20/2015 04:20 PM, Kirill A. Shutemov wrote:
> > We're going to allow mapping of individual 4k pages of THP compound.
> > It means we need to track mapcount on per small page basis.
> > 
> > Straight-forward approach is to use ->_mapcount in all subpages to track
> > how many time this subpage is mapped with PMDs or PTEs combined. But
> > this is rather expensive: mapping or unmapping of a THP page with PMD
> > would require HPAGE_PMD_NR atomic operations instead of single we have
> > now.
> > 
> > The idea is to store separately how many times the page was mapped as
> > whole -- compound_mapcount. This frees up ->_mapcount in subpages to
> > track PTE mapcount.
> > 
> > We use the same approach as with compound page destructor and compound
> > order to store compound_mapcount: use space in first tail page,
> > ->mapping this time.
> > 
> > Any time we map/unmap whole compound page (THP or hugetlb) -- we
> > increment/decrement compound_mapcount. When we map part of compound page
> > with PTE we operate on ->_mapcount of the subpage.
> > 
> > page_mapcount() counts both: PTE and PMD mappings of the page.
> > 
> > Basically, we have mapcount for a subpage spread over two counters.
> > It makes tricky to detect when last mapcount for a page goes away.
> > 
> > We introduced PageDoubleMap() for this. When we split THP PMD for the
> > first time and there's other PMD mapping left we offset up ->_mapcount
> > in all subpages by one and set PG_double_map on the compound page.
> > These additional references go away with last compound_mapcount.
> 
> So this stays even if all PTE mappings goes and the page is again mapped
> only with PMD. I'm not sure how often that happen and if it's an issue
> worth caring about.

We don't have a cheap way to detect this situation and it shouldn't
happen often enough to care.

-- 
 Kirill A. Shutemov

--
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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[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]