From: Andi Kleen <ak@linux.intel.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>,
peterz@infradead.org, linux-mm@kvack.org,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Don't touch single threaded PTEs which are on the right node
Date: Wed, 12 Oct 2016 08:40:33 -0700 [thread overview]
Message-ID: <20161012154033.GH3078@tassilo.jf.intel.com> (raw)
In-Reply-To: <20161012054933.GB20573@suse.de>
> You shouldn't need to check the number of mm_users and the node the task
> is running on for every PTE being scanned.
Ok.
>
> A more important corner case is if the VMA is shared with a task running on
> another node. By avoiding the NUMA hinting faults here, the hinting faults
> trapped by the remote process will appear exclusive and allow migration of
> the page. This will happen even if the single-threade task is continually
> using the pages.
>
> When you said "we had some problems", you didn't describe the workload or
> what the problems were (I'm assuming latency/jitter). Would restricting
> this check to private VMAs be sufficient?
The problem we ran into was that prefetches were not working, but
yes it would also cause extra latencies and jitter and in general
is unnecessary overhead.
It is super easy to reproduce. Just run main() {for(;;);}
It will eventually get some of its pages unmapped.
Yes doing it for private only would be fine. I'll add a check
for that.
-Andi
--
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:[~2016-10-12 15:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 20:28 [PATCH] Don't touch single threaded PTEs which are on the right node Andi Kleen
2016-10-12 5:49 ` Mel Gorman
2016-10-12 15:40 ` Andi Kleen [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-10-12 16:15 Andi Kleen
2016-10-13 8:39 ` Mel Gorman
2016-10-13 18:04 ` Andi Kleen
2016-10-13 18:16 ` Mel Gorman
2016-10-13 18:08 Andi Kleen
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=20161012154033.GH3078@tassilo.jf.intel.com \
--to=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=peterz@infradead.org \
/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).