linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: linux-mips@linux-mips.org, Andi Kleen <ak@linux.intel.com>,
	Alex Shi <alex.shu@intel.com>,
	Robert Richter <robert.richter@amd.com>,
	linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org, Jan Beulich <jbeulich@novell.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm@kvack.org, linux-sh@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, Mel Gorman <mgorman@suse.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH v3 6/7] mm: make clear_huge_page cache clear only around the fault address
Date: Thu, 16 Aug 2012 18:16:47 +0200	[thread overview]
Message-ID: <20120816161647.GM11188@redhat.com> (raw)
In-Reply-To: <1345130154-9602-7-git-send-email-kirill.shutemov@linux.intel.com>

Hi Kirill,

On Thu, Aug 16, 2012 at 06:15:53PM +0300, Kirill A. Shutemov wrote:
>  	for (i = 0; i < pages_per_huge_page;
>  	     i++, p = mem_map_next(p, page, i)) {

It may be more optimal to avoid a multiplication/shiftleft before the
add, and to do:

  	for (i = 0, vaddr = haddr; i < pages_per_huge_page;
  	     i++, p = mem_map_next(p, page, i), vaddr += PAGE_SIZE) {

>  		cond_resched();
> -		clear_user_highpage(p, addr + i * PAGE_SIZE);
> +		vaddr = haddr + i*PAGE_SIZE;

Not sure if gcc can optimize it away because of the external calls.

> +		if (!ARCH_HAS_USER_NOCACHE || i == target)
> +			clear_user_highpage(page + i, vaddr);
> +		else
> +			clear_user_highpage_nocache(page + i, vaddr);
>  	}


My only worry overall is if there can be some workload where this may
actually slow down userland if the CPU cache is very large and
userland would access most of the faulted in memory after the first
fault.

So I wouldn't mind to add one more check in addition of
!ARCH_HAS_USER_NOCACHE above to check a runtime sysctl variable. It'll
waste a cacheline yes but I doubt it's measurable compared to the time
it takes to do a >=2M hugepage copy.

Furthermore it would allow people to benchmark its effect without
having to rebuild the kernel themself.

All other patches looks fine to me.

Thanks!
Andrea

  reply	other threads:[~2012-08-16 16:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 15:15 [PATCH v3 0/7] Avoid cache trashing on clearing huge/gigantic page Kirill A. Shutemov
2012-08-16 15:15 ` [PATCH v3 1/7] THP: Use real address for NUMA policy Kirill A. Shutemov
2012-08-16 15:15 ` [PATCH v3 2/7] THP: Pass fault address to __do_huge_pmd_anonymous_page() Kirill A. Shutemov
2012-08-16 15:15 ` [PATCH v3 3/7] hugetlb: pass fault address to hugetlb_no_page() Kirill A. Shutemov
2012-08-16 15:15 ` [PATCH v3 4/7] mm: pass fault address to clear_huge_page() Kirill A. Shutemov
2012-08-16 15:15 ` [PATCH v3 5/7] x86: Add clear_page_nocache Kirill A. Shutemov
2012-08-16 15:15 ` [PATCH v3 6/7] mm: make clear_huge_page cache clear only around the fault address Kirill A. Shutemov
2012-08-16 16:16   ` Andrea Arcangeli [this message]
2012-08-16 16:43     ` Kirill A. Shutemov
2012-08-16 18:29       ` Andrea Arcangeli
2012-08-16 18:37         ` Kirill A. Shutemov
2012-08-16 19:42           ` Andrea Arcangeli
2012-08-16 15:15 ` [PATCH v3 7/7] x86: switch the 64bit uncached page clear to SSE/AVX v2 Kirill A. Shutemov

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=20120816161647.GM11188@redhat.com \
    --to=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shu@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=jbeulich@novell.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@amacapital.net \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=robert.richter@amd.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=x86@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).