linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Shaohua Li <shli@kernel.org>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hughd@google.com,
	riel@redhat.com, mel@csn.ul.ie
Subject: Re: [patch]x86: clearing access bit don't flush tlb
Date: Wed, 2 Apr 2014 14:01:43 +0100	[thread overview]
Message-ID: <20140402130143.GA1869@suse.de> (raw)
In-Reply-To: <20140326223034.GA31713@kernel.org>

On Thu, Mar 27, 2014 at 06:30:34AM +0800, Shaohua Li wrote:
> 
> I posted this patch a year ago or so, but it gets lost. Repost it here to check
> if we can make progress this time.
> 
> We use access bit to age a page at page reclaim. When clearing pte access bit,
> we could skip tlb flush in X86. The side effect is if the pte is in tlb and pte
> access bit is unset in page table, when cpu access the page again, cpu will not
> set page table pte's access bit. Next time page reclaim will think this hot
> page is old and reclaim it wrongly, but this doesn't corrupt data.
> 
> And according to intel manual, tlb has less than 1k entries, which covers < 4M
> memory. In today's system, several giga byte memory is normal. After page
> reclaim clears pte access bit and before cpu access the page again, it's quite
> unlikely this page's pte is still in TLB. And context swich will flush tlb too.
> The chance skiping tlb flush to impact page reclaim should be very rare.
> 
> Originally (in 2.5 kernel maybe), we didn't do tlb flush after clear access bit.
> Hugh added it to fix some ARM and sparc issues. Since I only change this for
> x86, there should be no risk.
> 
> And in some workloads, TLB flush overhead is very heavy. In my simple
> multithread app with a lot of swap to several pcie SSD, removing the tlb flush
> gives about 20% ~ 30% swapout speedup.
> 
> Signed-off-by: Shaohua Li <shli@fusionio.com>

I'm aware of the discussion on the more complex version and the outcome
of that. While I think the corner case is real, I think it's also very
unlikely and as this is an x86-only thing which will be safe from
corruption at least;

Acked-by: Mel Gorman <mgorman@suse.de>

Shaohua, you almost certainly should resend this to Andrew with the
ack's you collected so that he does not have to dig into the history
trying to figure out what the exact story is.

Thanks.

-- 
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>

  parent reply	other threads:[~2014-04-02 13:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 22:30 [patch]x86: clearing access bit don't flush tlb Shaohua Li
2014-03-26 23:55 ` Rik van Riel
2014-03-27 17:12   ` Shaohua Li
2014-03-27 18:41     ` Rik van Riel
2014-03-28 19:02       ` Shaohua Li
2014-03-30 12:58         ` Rik van Riel
2014-03-31  2:16           ` Shaohua Li
2014-04-02 13:01 ` Mel Gorman [this message]
2014-04-02 15:42   ` Hugh Dickins
  -- strict thread matches above, loose matches on Subject: below --
2014-04-03  0:42 Shaohua Li
2014-04-03 11:35 ` [patch] x86: " Ingo Molnar
2014-04-03 13:45   ` Shaohua Li
2014-04-04 15:01     ` Johannes Weiner
2014-04-08  7:58   ` Shaohua Li
2014-04-14 11:36     ` Ingo Molnar

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=20140402130143.GA1869@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=riel@redhat.com \
    --cc=shli@kernel.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).