From: Mel Gorman <mgorman@suse.de>
To: Henry Willard <henry.willard@oracle.com>
Cc: akpm@linux-foundation.org, kstewart@linuxfoundation.org,
zi.yan@cs.rutgers.edu, pombredanne@nexb.com, aarcange@redhat.com,
gregkh@linuxfoundation.org, aneesh.kumar@linux.vnet.ibm.com,
kirill.shutemov@linux.intel.com, jglisse@redhat.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: numa: Do not trap faults on shared data section pages.
Date: Tue, 16 Jan 2018 21:26:14 +0000 [thread overview]
Message-ID: <20180116212614.gudglzw7kwzd3get@suse.de> (raw)
In-Reply-To: <1516130924-3545-2-git-send-email-henry.willard@oracle.com>
On Tue, Jan 16, 2018 at 11:28:44AM -0800, Henry Willard wrote:
> Workloads consisting of a large number processes running the same program
> with a large shared data section may suffer from excessive numa balancing
> page migration of the pages in the shared data section. This shows up as
> high I/O wait time and degraded performance on machines with higher socket
> or node counts.
>
> This patch skips shared copy-on-write pages in change_pte_range() for the
> numa balancing case.
>
> Signed-off-by: Henry Willard <henry.willard@oracle.com>
> Reviewed-by: Hakon Bugge <haakon.bugge@oracle.com>
> Reviewed-by: Steve Sistare steven.sistare@oracle.com
Merge the leader and this mail together. It would have been nice to see
data on other realistic workloads as well.
My main source of discomfort is the fact that this is permanent as two
processes perfectly isolated but with a suitably shared COW mapping
will never migrate the data. A potential improvement to get the reported
bandwidth up in the test program would be to skip the rest of the VMA if
page_mapcount != 1 in a COW mapping as it would be reasonable to assume
the remaining pages in the VMA are also affected and the scan is wasteful.
There are counter-examples to this but I suspect that the full VMA being
shared is the common case. Whether you do that or not;
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
SUSE Labs
--
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:[~2018-01-16 21:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 19:28 [PATCH] mm: numa: numa balancing performance problem Henry Willard
2018-01-16 19:28 ` [PATCH] mm: numa: Do not trap faults on shared data section pages Henry Willard
2018-01-16 21:26 ` Mel Gorman [this message]
2018-01-17 0:45 ` Henry Willard
2018-01-17 18:23 ` Christopher Lameter
2018-01-19 1:06 ` Henry Willard
2018-01-20 2:12 ` Christopher Lameter
2018-01-23 0:41 ` Henry Willard
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=20180116212614.gudglzw7kwzd3get@suse.de \
--to=mgorman@suse.de \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=henry.willard@oracle.com \
--cc=jglisse@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pombredanne@nexb.com \
--cc=zi.yan@cs.rutgers.edu \
/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