All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Dave Jones <davej@redhat.com>, Zachary Amsden <zach@vmware.com>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@muc.de>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Chris Wright <chrisw@sous-sol.org>,
	Hugh Dickins <hugh@veritas.com>,
	David Rientjes <rientjes@google.com>,
	Michel Lespinasse <walken@vmware.com>,
	Virtualization Mailing List <virtualization@lists.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] Pte xchg optimization.patch
Date: Thu, 12 Apr 2007 11:44:26 -0700	[thread overview]
Message-ID: <461E7E0A.60002@vmware.com> (raw)
In-Reply-To: <20070412181809.GC25646@redhat.com>

Dave Jones wrote:
> On Wed, Apr 11, 2007 at 10:30:58PM -0700, Zachary Amsden wrote:
>  > In situations where page table updates need only be made locally, and there
>  > is no cross-processor A/D bit races involved, we need not use the heavyweight
>  > xchg instruction to atomically fetch and clear page table entries.  Instead,
>  > we can just read and clear them directly.
>  > 
>  > This introduces a neat optimization for non-SMP kernels; drop the atomic
>  > xchg operations from page table updates.
>
> Would it be feasible to do this using the smp_alternatives stuff?
> Given many distros are now shipping SMP-only kernels, it'd be nice
> to get that win without using having to rebuild their kernels.
>   

That's a good point. It is a fairly straightforward substitution for the 
static case:

xchg reg, mem

to

mov mem, reg
mov imm, mem

I'll give it a spin and see how it drives. It is, though, less obvious 
how easy it will be for PAE kernels.

Zach

      reply	other threads:[~2007-04-12 18:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-12  5:30 [PATCH 3/4] Pte xchg optimization.patch Zachary Amsden
2007-04-12 18:18 ` Dave Jones
2007-04-12 18:18   ` Dave Jones
2007-04-12 18:44   ` Zachary Amsden [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=461E7E0A.60002@vmware.com \
    --to=zach@vmware.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=davej@redhat.com \
    --cc=hugh@veritas.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.osdl.org \
    --cc=walken@vmware.com \
    /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.