From: Andrew Morton <akpm@linux-foundation.org>
To: Michel Lespinasse <walken@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
Hugh Dickins <hughd@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm: accelerate mm_populate() treatment of THP pages
Date: Fri, 1 Feb 2013 16:08:23 -0800 [thread overview]
Message-ID: <20130201160823.f88f222f.akpm@linux-foundation.org> (raw)
In-Reply-To: <1359591980-29542-3-git-send-email-walken@google.com>
On Wed, 30 Jan 2013 16:26:19 -0800
Michel Lespinasse <walken@google.com> wrote:
> This change adds a page_mask argument to follow_page.
>
> follow_page sets *page_mask to HPAGE_PMD_NR - 1 when it encounters a THP page,
> and to 0 in other cases.
>
> __get_user_pages() makes use of this in order to accelerate populating
> THP ranges - that is, when both the pages and vmas arrays are NULL,
> we don't need to iterate HPAGE_PMD_NR times to cover a single THP page
> (and we also avoid taking mm->page_table_lock that many times).
>
> Other follow_page() call sites can safely ignore the value returned in
> *page_mask.
Seems sensible, but the implementation is rather ungainly.
If we're going to add this unused page_mask local to many functions
then let's at least miminize the scope of that variable and explain why
it's there. For example,
--- a/mm/ksm.c~mm-accelerate-mm_populate-treatment-of-thp-pages-fix
+++ a/mm/ksm.c
@@ -356,9 +356,10 @@ static int break_ksm(struct vm_area_stru
{
struct page *page;
int ret = 0;
- long page_mask;
do {
+ long page_mask; /* unused */
+
cond_resched();
page = follow_page(vma, addr, FOLL_GET, &page_mask);
if (IS_ERR_OR_NULL(page))
@@ -454,7 +455,7 @@ static struct page *get_mergeable_page(s
unsigned long addr = rmap_item->address;
struct vm_area_struct *vma;
struct page *page;
- long page_mask;
+ long page_mask; /* unused */
down_read(&mm->mmap_sem);
vma = find_mergeable_vma(mm, addr);
@@ -1525,7 +1526,6 @@ static struct rmap_item *scan_get_next_r
struct mm_slot *slot;
struct vm_area_struct *vma;
struct rmap_item *rmap_item;
- long page_mask;
int nid;
if (list_empty(&ksm_mm_head.mm_list))
@@ -1600,6 +1600,8 @@ next_mm:
ksm_scan.address = vma->vm_end;
while (ksm_scan.address < vma->vm_end) {
+ long page_mask; /* unused */
+
if (ksm_test_exit(mm))
break;
*page = follow_page(vma, ksm_scan.address, FOLL_GET,
Alternatively we could permit the passing of page_mask==NULL, which is
a common convention in the get_user_pages() area. Possibly that's a
tad more expensive, but it will save a stack slot.
However I think the best approach here is to just leave the
follow_page() interface alone. Rename the present implementation to
follow_page_mask() or whatever and add
static inline<?> void follow_page(args)
{
long page_mask; /* unused */
return follow_page_mask(args, &page_mask);
}
Also, I see no sense in permitting negative page_mask values and I
doubt if we'll be needing 64-bit values here. Make it `unsigned int'?
Finally, this version of the patch surely breaks the nommu build?
--
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>
next prev parent reply other threads:[~2013-02-02 0:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-31 0:26 [PATCH 0/3] fixes for large mm_populate() and munlock() operations Michel Lespinasse
2013-01-31 0:26 ` [PATCH 1/3] mm: use long type for page counts in mm_populate() and get_user_pages() Michel Lespinasse
2013-01-31 0:42 ` Andrew Morton
2013-02-07 0:39 ` Sasha Levin
2013-02-07 1:10 ` Andrew Morton
2013-02-07 1:16 ` Sasha Levin
2013-02-07 21:35 ` Michel Lespinasse
2013-01-31 0:26 ` [PATCH 2/3] mm: accelerate mm_populate() treatment of THP pages Michel Lespinasse
2013-01-31 3:05 ` Hugh Dickins
2013-01-31 4:27 ` Michel Lespinasse
2013-02-02 0:08 ` Andrew Morton [this message]
2013-01-31 0:26 ` [RFC PATCH 3/3] mm: accelerate munlock() " Michel Lespinasse
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=20130201160823.f88f222f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=aarcange@redhat.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--cc=walken@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).