From: Simon Jeons <simon.jeons@gmail.com>
To: Shaohua Li <shli@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, mingo@redhat.com, hpa@zytor.com,
riel@redhat.com
Subject: Re: [RFC]x86: clearing access bit don't flush tlb
Date: Mon, 07 Jan 2013 21:14:54 -0600 [thread overview]
Message-ID: <1357614894.4105.10.camel@kernel.cn.ibm.com> (raw)
In-Reply-To: <20130107081213.GA21779@kernel.org>
Hi Shaohua,
On Mon, 2013-01-07 at 16:12 +0800, Shaohua Li wrote:
> We use access bit to age a page at page reclaim. When clearing pte access bit,
Who sets this flag to pte? mmu? tlb?
> we could skip tlb flush for the virtual address. The side effect is if the pte
> is in tlb and pte access bit is unset, when cpu access the page again, cpu will
> not set pte's access bit. So next time page reclaim can reclaim hot pages
> wrongly, but this doesn't corrupt anything. And according to intel manual, tlb
> has less than 1k entries, which coverers < 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. Skiping the tlb flush for this case sounds ok to me.
>
If one page is accessed more frequently than the other page before page
reclaim, page reclaim treat them the same hot according to access flag
since the flag used to age page just at page reclaim. How to handle this
issue?
> 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>
> ---
> arch/x86/mm/pgtable.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> Index: linux/arch/x86/mm/pgtable.c
> ===================================================================
> --- linux.orig/arch/x86/mm/pgtable.c 2012-12-17 16:54:37.847770807 +0800
> +++ linux/arch/x86/mm/pgtable.c 2013-01-07 14:59:40.898066357 +0800
> @@ -376,13 +376,8 @@ int pmdp_test_and_clear_young(struct vm_
> int ptep_clear_flush_young(struct vm_area_struct *vma,
> unsigned long address, pte_t *ptep)
> {
> - int young;
>
> - young = ptep_test_and_clear_young(vma, address, ptep);
> - if (young)
> - flush_tlb_page(vma, address);
> -
> - return young;
> + return ptep_test_and_clear_young(vma, address, ptep);
> }
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>
> --
> 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>
--
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>
prev parent reply other threads:[~2013-01-08 3:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 8:12 [RFC]x86: clearing access bit don't flush tlb Shaohua Li
2013-01-07 15:14 ` Rik van Riel
2013-01-07 22:31 ` H. Peter Anvin
2013-01-08 4:55 ` Shaohua Li
2013-01-08 5:03 ` H. Peter Anvin
2013-01-08 5:08 ` Rik van Riel
2013-01-08 5:09 ` H. Peter Anvin
2013-01-08 7:03 ` Rik van Riel
2013-01-15 1:41 ` Shaohua Li
2013-01-08 3:14 ` Simon Jeons [this message]
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=1357614894.4105.10.camel@kernel.cn.ibm.com \
--to=simon.jeons@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--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).