linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	mhocko@kernel.org, vbabka@suse.cz, Aaron Lu <aaron.lu@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mremap: Avoid TLB flushing anonymous pages that are not in swap cache
Date: Tue, 5 Jun 2018 12:49:18 -0700	[thread overview]
Message-ID: <ecb75c29-3d1b-3b5e-ec9d-59c4f6c1ef08@intel.com> (raw)
In-Reply-To: <20180605191245.3owve7gfut22tyob@techsingularity.net>

On 06/05/2018 12:12 PM, Mel Gorman wrote:
> That's fair enough. I updated part of the changelog to read
> 
> This patch special cases anonymous pages to only flush ranges under the
> page table lock if the page is in swap cache and can be potentially queued
> for IO. Note that the full flush of the range being mremapped is still
> flushed so TLB flushes are not eliminated entirely.
> 
> Does that work for you?

Looks good, thanks.

>> I usually try to make the non-pte-modifying functions take a pte_t
>> instead of 'pte_t *' to make it obvious that there no modification going
>> on.  Any reason not to do that here?
> 
> No, it was just a minor saving on stack usage.

We're just splitting hairs now :) but, realistically, this little helper
will get inlined anyway, so it probably all generates the same code.

...
>> BTW, do you want to add a tiny comment about why we do the
>> trylock_page()?  I assume it's because we don't want to wait on finding
>> an exact answer: we just assume it is in the swap cache if the page is
>> locked and flush regardless.
> 
> It's really because calling lock_page while holding a spinlock is
> eventually going to ruin your day.

Hah, yeah, that'll do it.  Could you comment this, too?

  reply	other threads:[~2018-06-05 19:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 17:13 Mel Gorman
2018-06-05 18:18 ` Dave Hansen
2018-06-05 19:12   ` Mel Gorman
2018-06-05 19:49     ` Dave Hansen [this message]
2018-06-05 19:51       ` Mel Gorman
2018-06-05 19:54         ` Dave Hansen
2018-06-05 20:00           ` Mel Gorman
2018-06-06  8:22         ` Michal Hocko
2018-06-05 19:53 ` Nadav Amit
2018-06-05 20:08   ` Mel Gorman
2018-06-05 22:53     ` Nadav Amit

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=ecb75c29-3d1b-3b5e-ec9d-59c4f6c1ef08@intel.com \
    --to=dave.hansen@intel.com \
    --cc=aaron.lu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox