Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1197089 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv9 26/36] mm: rework mapcount accounting to enable 4k mapping  of THPs Jerome Marchand <jmarchan@redhat.com> - 2015-07-31 17:10 +0200
    Re: [PATCHv9 26/36] mm: rework mapcount accounting to enable 4k  mapping of THPs "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-08-03 12:50 +0200
      Re: [PATCHv9 26/36] mm: rework mapcount accounting to enable 4k mapping  of THPs Jerome Marchand <jmarchan@redhat.com> - 2015-08-03 13:50 +0200

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

[Multipart message — attachments visible in raw view] — view raw

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.

Acked-by: Jerome Marchand <jmarchan@redhat.com>

> 
> This approach provides a way to detect when last mapcount goes away on
> per small page basis without introducing new overhead for most common
> cases.
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
>  include/linux/mm.h         | 26 +++++++++++-
>  include/linux/mm_types.h   |  1 +
>  include/linux/page-flags.h | 37 +++++++++++++++++
>  include/linux/rmap.h       |  4 +-
>  mm/debug.c                 |  5 ++-
>  mm/huge_memory.c           |  2 +-
>  mm/hugetlb.c               |  4 +-
>  mm/memory.c                |  2 +-
>  mm/migrate.c               |  2 +-
>  mm/page_alloc.c            | 14 +++++--
>  mm/rmap.c                  | 99 +++++++++++++++++++++++++++++++++++-----------
>  11 files changed, 161 insertions(+), 35 deletions(-)
> 

[toc] | [next] | [standalone]

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

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1198776

[Multipart message — attachments visible in raw view] — view raw

On 08/03/2015 12:43 PM, Kirill A. Shutemov wrote:
> 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.
> 

I thought so.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web