All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Lutomirski <luto@mit.edu>,
	linux-kernel@vger.kernel.org, x86 <x86@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [RFC] syscall calling convention, stts/clts, and xstate latency
Date: Mon, 25 Jul 2011 10:42:15 +0300	[thread overview]
Message-ID: <4E2D1E57.1080404@redhat.com> (raw)
In-Reply-To: <20110724211526.GA6785@elte.hu>

On 07/25/2011 12:15 AM, Ingo Molnar wrote:
> >  All of this makes me think that, at least on Sandy Bridge, lazy
> >  xstate saving is a bad optimization -- if the cache is being nice,
> >  save/restore is faster than twiddling the TS bit.  And the cost of
> >  the trap when TS is set blows everything else away.
>
> Interesting. Mind cooking up a delazying patch and measure it on
> native as well? KVM generally makes exceptions more expensive, so the
> effect of lazy exceptions might be less on native.

While this is true in general, kvm will trap #NM only after a host 
context switch or an exit to host userspace.  These are supposedly rare 
so you won't see them a lot, especially in a benchmark scenario with 
just one guest.

("host context switch" includes switching to the idle thread when the 
guest executes HLT, something I tried to optimize in the past but it 
proved too difficult for the gain)

-- 
error compiling committee.c: too many arguments to function


  parent reply	other threads:[~2011-07-25  7:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-24 21:07 [RFC] syscall calling convention, stts/clts, and xstate latency Andrew Lutomirski
2011-07-24 21:15 ` Ingo Molnar
2011-07-24 22:34   ` Andrew Lutomirski
2011-07-25  3:21     ` Andrew Lutomirski
2011-07-25  6:42       ` Ingo Molnar
2011-07-25 10:05       ` [PATCH 3.1?] x86: Remove useless stts/clts pair in __switch_to Andy Lutomirski
2011-07-25 11:12         ` Ingo Molnar
2011-07-25 13:04           ` Andrew Lutomirski
2011-07-25 14:13             ` Ingo Molnar
2011-07-25  6:38     ` [RFC] syscall calling convention, stts/clts, and xstate latency Ingo Molnar
2011-07-25  9:44       ` Andrew Lutomirski
2011-07-25  9:51         ` Ingo Molnar
2011-07-25 11:04         ` Hans Rosenfeld
2011-07-25  7:42   ` Avi Kivity [this message]
2011-07-25  7:54     ` 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=4E2D1E57.1080404@redhat.com \
    --to=avi@redhat.com \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --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 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.