From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default
Date: Fri, 26 Feb 2016 13:32:53 +0300 [thread overview]
Message-ID: <20160226103253.GA22450@node.shutemov.name> (raw)
In-Reply-To: <20160225190144.GE1180@redhat.com>
On Thu, Feb 25, 2016 at 08:01:44PM +0100, Andrea Arcangeli wrote:
> Another problem is that khugepaged isn't able to collapse shared
> readonly anon pages, mostly because of the rmap complexities. I agree
> with Kirill we should be looking into how make this work, although I
> doubt the simpler refcounting is going to help much in this regard as
> the problem is in dealing with rmap, not so much with refcounts.
Could you elaborate on problems with rmap? I have looked into this deeply
yet.
Do you see anything what would prevent following basic scheme:
- Identify series of small pages as candidate for collapsing into
a compound page. Not sure how difficult it would be. I guess it can be
done by looking for adjacent pages which belong to the same anon_vma.
- Setup migration entries for pte which maps these pages.
- Collapse small pages into compound page. IIUC, it only will be possible
if these pages are not pinned.
- Replace migration entries with ptes which point to subpages of the new
compound page.
- Scan over all vmas mapping this compound page, looking for VMA suitable
for huge page. We cannot collapse it right away due lock inversion of
anon_vma->rwsem vs. mmap_sem.
- For found VMAs, collapse page table into PMD one VMA a time under
down_write(mmap_sem).
Even if would fail to create any PMDs, we would reduce LRU pressure by
collapsing small pages into compound one.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default
Date: Fri, 26 Feb 2016 13:32:53 +0300 [thread overview]
Message-ID: <20160226103253.GA22450@node.shutemov.name> (raw)
In-Reply-To: <20160225190144.GE1180@redhat.com>
On Thu, Feb 25, 2016 at 08:01:44PM +0100, Andrea Arcangeli wrote:
> Another problem is that khugepaged isn't able to collapse shared
> readonly anon pages, mostly because of the rmap complexities. I agree
> with Kirill we should be looking into how make this work, although I
> doubt the simpler refcounting is going to help much in this regard as
> the problem is in dealing with rmap, not so much with refcounts.
Could you elaborate on problems with rmap? I have looked into this deeply
yet.
Do you see anything what would prevent following basic scheme:
- Identify series of small pages as candidate for collapsing into
a compound page. Not sure how difficult it would be. I guess it can be
done by looking for adjacent pages which belong to the same anon_vma.
- Setup migration entries for pte which maps these pages.
- Collapse small pages into compound page. IIUC, it only will be possible
if these pages are not pinned.
- Replace migration entries with ptes which point to subpages of the new
compound page.
- Scan over all vmas mapping this compound page, looking for VMA suitable
for huge page. We cannot collapse it right away due lock inversion of
anon_vma->rwsem vs. mmap_sem.
- For found VMAs, collapse page table into PMD one VMA a time under
down_write(mmap_sem).
Even if would fail to create any PMDs, we would reduce LRU pressure by
collapsing small pages into compound one.
--
Kirill A. Shutemov
next prev parent reply other threads:[~2016-02-26 10:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 17:12 [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default Mel Gorman
2016-02-25 17:12 ` Mel Gorman
2016-02-25 18:32 ` Rik van Riel
2016-02-25 19:07 ` Mel Gorman
2016-02-25 19:07 ` Mel Gorman
2016-02-25 19:01 ` Andrea Arcangeli
2016-02-25 19:01 ` Andrea Arcangeli
2016-02-25 19:56 ` Mel Gorman
2016-02-25 19:56 ` Mel Gorman
2016-02-25 23:02 ` Andrea Arcangeli
2016-02-25 23:02 ` Andrea Arcangeli
2016-02-25 23:08 ` Andrea Arcangeli
2016-02-25 23:08 ` Andrea Arcangeli
2016-02-26 11:13 ` Mel Gorman
2016-02-26 11:13 ` Mel Gorman
2016-02-26 19:50 ` Andrea Arcangeli
2016-02-26 19:50 ` Andrea Arcangeli
2016-02-26 20:46 ` Mel Gorman
2016-02-26 20:46 ` Mel Gorman
2016-02-26 10:32 ` Kirill A. Shutemov [this message]
2016-02-26 10:32 ` Kirill A. Shutemov
2016-03-02 18:47 ` Andrea Arcangeli
2016-03-02 18:47 ` Andrea Arcangeli
2016-02-25 19:45 ` Johannes Weiner
2016-02-25 19:45 ` Johannes Weiner
2016-02-26 10:52 ` Mel Gorman
2016-02-26 10:52 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160226103253.GA22450@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=riel@redhat.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.