All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@kernel.org>,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH 0/3] Virtual huge zero page
Date: Mon, 1 Oct 2012 18:31:18 +0200	[thread overview]
Message-ID: <20121001163118.GC18051@redhat.com> (raw)
In-Reply-To: <5069B804.6040902@linux.intel.com>

On Mon, Oct 01, 2012 at 08:34:28AM -0700, H. Peter Anvin wrote:
> On 09/29/2012 06:48 AM, Andrea Arcangeli wrote:
> > 
> > There would be a small cache benefit here... but even then some first
> > level caches are virtually indexed IIRC (always physically tagged to
> > avoid the software to notice) and virtually indexed ones won't get any
> > benefit.
> > 
> 
> Not quite.  The virtual indexing is limited to a few bits (e.g. three
> bits on K8); the right way to deal with that is to color the zeropage,
> both the regular one and the virtual one (the virtual one would circle
> through all the colors repeatedly.)
> 
> The cache difference, therefore, is *huge*.

Kirill measured the cache benefit and it provided a 6% gain, not very
huge but certainly significant.

> It's a performance tradeoff, and it can, and should, be measured.

I now measured the other side of the trade, by touching only one
character every 4k page in the range to simulate a very seeking load,
and doing so the physical huge zero page wins with a 600% margin, so
if the cache benefit is huge for the virtual zero page, the TLB
benefit is massive for the physical zero page.

Overall I think picking the solution that risks to regress the least
(also compared to current status of no zero page) is the safest.

Thanks!
Andrea

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@kernel.org>,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH 0/3] Virtual huge zero page
Date: Mon, 1 Oct 2012 18:31:18 +0200	[thread overview]
Message-ID: <20121001163118.GC18051@redhat.com> (raw)
In-Reply-To: <5069B804.6040902@linux.intel.com>

On Mon, Oct 01, 2012 at 08:34:28AM -0700, H. Peter Anvin wrote:
> On 09/29/2012 06:48 AM, Andrea Arcangeli wrote:
> > 
> > There would be a small cache benefit here... but even then some first
> > level caches are virtually indexed IIRC (always physically tagged to
> > avoid the software to notice) and virtually indexed ones won't get any
> > benefit.
> > 
> 
> Not quite.  The virtual indexing is limited to a few bits (e.g. three
> bits on K8); the right way to deal with that is to color the zeropage,
> both the regular one and the virtual one (the virtual one would circle
> through all the colors repeatedly.)
> 
> The cache difference, therefore, is *huge*.

Kirill measured the cache benefit and it provided a 6% gain, not very
huge but certainly significant.

> It's a performance tradeoff, and it can, and should, be measured.

I now measured the other side of the trade, by touching only one
character every 4k page in the range to simulate a very seeking load,
and doing so the physical huge zero page wins with a 600% margin, so
if the cache benefit is huge for the virtual zero page, the TLB
benefit is massive for the physical zero page.

Overall I think picking the solution that risks to regress the least
(also compared to current status of no zero page) is the safest.

Thanks!
Andrea

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

  reply	other threads:[~2012-10-01 16:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-28 23:37 [PATCH 0/3] Virtual huge zero page Kirill A. Shutemov
2012-09-28 23:37 ` Kirill A. Shutemov
2012-09-28 23:37 ` [PATCH 1/3] asm-generic: introduce pmd_special() and pmd_mkspecial() Kirill A. Shutemov
2012-09-28 23:37   ` Kirill A. Shutemov
2012-09-28 23:37 ` [PATCH 2/3] mm, thp: implement virtual huge zero page Kirill A. Shutemov
2012-09-28 23:37   ` Kirill A. Shutemov
2012-09-28 23:37 ` [PATCH 3/3] x86: implement HAVE_PMD_SPECAIL Kirill A. Shutemov
2012-09-28 23:37   ` Kirill A. Shutemov
2012-09-29 13:48 ` [PATCH 0/3] Virtual huge zero page Andrea Arcangeli
2012-09-29 13:48   ` Andrea Arcangeli
2012-09-29 14:30   ` Andi Kleen
2012-09-29 14:30     ` Andi Kleen
2012-09-29 14:30     ` Andi Kleen
2012-09-29 14:37     ` Andrea Arcangeli
2012-09-29 14:37       ` Andrea Arcangeli
2012-10-01 13:49       ` Kirill A. Shutemov
2012-10-01 16:14         ` Andrea Arcangeli
2012-10-01 16:14           ` Andrea Arcangeli
2012-10-01 17:18           ` Kirill A. Shutemov
2012-10-01 17:18             ` Kirill A. Shutemov
2012-10-01 15:34   ` H. Peter Anvin
2012-10-01 15:34     ` H. Peter Anvin
2012-10-01 16:31     ` Andrea Arcangeli [this message]
2012-10-01 16:31       ` Andrea Arcangeli
2012-10-01 17:03       ` H. Peter Anvin
2012-10-01 17:03         ` H. Peter Anvin
2012-10-01 17:15         ` Kirill A. Shutemov
2012-10-01 17:15           ` Kirill A. Shutemov
2012-10-01 18:03           ` Andrea Arcangeli
2012-10-01 18:03             ` Andrea Arcangeli
2012-10-01 17:26         ` Andrea Arcangeli
2012-10-01 17:26           ` Andrea Arcangeli
2012-10-01 17:33           ` H. Peter Anvin
2012-10-01 17:33             ` H. Peter Anvin
2012-10-01 17:36             ` Kirill A. Shutemov
2012-10-01 17:36               ` Kirill A. Shutemov
2012-10-01 17:37               ` H. Peter Anvin
2012-10-01 17:37                 ` H. Peter Anvin
2012-10-01 17:44                 ` Kirill A. Shutemov
2012-10-01 17:44                   ` Kirill A. Shutemov
2012-10-01 17:52                   ` H. Peter Anvin
2012-10-01 17:52                     ` H. Peter Anvin
2012-10-01 18:56                     ` Kirill A. Shutemov
2012-10-01 18:56                       ` Kirill A. Shutemov
2012-10-01 18:05             ` Andrea Arcangeli
2012-10-01 18:05               ` Andrea Arcangeli

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=20121001163118.GC18051@redhat.com \
    --to=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=hpa@linux.intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.