From: Avi Kivity <avi@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>,
Sheng Yang <sheng@linux.intel.com>,
Joerg Roedel <joerg.roedel@amd.com>
Cc: kvm@vger.kernel.org, Lucas Meneghel Rodrigues <lmr@redhat.com>
Subject: Re: [PATCH 4/5] KVM: Lazify fpu activation and deactivation
Date: Thu, 14 Jan 2010 15:11:53 +0200 [thread overview]
Message-ID: <4B4F1819.7040105@redhat.com> (raw)
In-Reply-To: <4B4F17F0.7010501@redhat.com>
(actually copying Lucas).
On 01/14/2010 03:11 PM, Avi Kivity wrote:
> On 12/30/2009 06:25 PM, Avi Kivity wrote:
>> Defer fpu deactivation as much as possible - if the guest fpu is
>> loaded, keep
>> it loaded until the next heavyweight exit (where we are forced to
>> unload it).
>> This reduces unnecessary exits.
>>
>> We also defer fpu activation on clts; while clts signals the intent
>> to use the
>> fpu, we can't be sure the guest will actually use it.
>>
>
> ...
>
>
>> @@ -4988,6 +4988,10 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
>> return;
>>
>> vcpu->guest_fpu_loaded = 0;
>> + if (vcpu->fpu_active) {
>> + vcpu->fpu_active = 0;
>> + kvm_x86_ops->fpu_deactivate(vcpu);
>> + }
>> kvm_fx_save(&vcpu->arch.guest_fx_image);
>> kvm_fx_restore(&vcpu->arch.host_fx_image);
>> ++vcpu->stat.fpu_reload;
>
> This is broken badly; kvm_put_guest_fpu() can be called from preempt
> notifier context, that is during normal execution of vcpu processing.
> Code which modifies the same variables as ->fpu_deactivate() or that
> depends on ->fpu_active will break.
>
> I fixed this by calling ->fpu_deactivate() from a synchronous context
> using vcpu->requests, like we do everywhere else.
>
> Strangely, autotest only caught this on AMD and even it took a while.
> Lucas, can you integrate something like the following into autotest,
> so we exercise the preemption code harder?
>
> #!/usr/bin/python
>
> import sys, os, re, random, ctypes, time
>
> tasks = sys.argv[1:]
>
> threads = [int(t)
> for k in tasks
> for t in os.listdir('/proc/%s/task' % (k,))]
>
> cpus = [int(c[3:])
> for c in os.listdir('/sys/devices/system/cpu')
> if re.match(r'cpu[0-9]+', c)]
>
> rand = random.Random()
>
> sched_setaffinity = ctypes.CDLL('libc.so.6').sched_setaffinity
>
> while True:
> pid = rand.choice(threads)
> cpu = rand.choice(cpus)
> mask = 1 << cpu
> sched_setaffinity(ctypes.c_int(pid), ctypes.c_size_t(4),
> ctypes.byref(ctypes.c_int(mask)))
> try:
> time.sleep(0.01)
> except:
> break
>
>
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-01-14 13:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-30 16:25 [PATCH 0/5] Lazy fpu, cr0.ts Avi Kivity
2009-12-30 16:25 ` [PATCH 1/5] KVM: VMX: trace clts and lmsw instructions as cr accesses Avi Kivity
2009-12-30 16:25 ` [PATCH 2/5] KVM: Replace read accesses of vcpu->arch.cr0 by an accessor Avi Kivity
2009-12-30 16:25 ` [PATCH 3/5] KVM: VMX: Allow the guest to own some cr0 bits Avi Kivity
2009-12-30 16:25 ` [PATCH 4/5] KVM: Lazify fpu activation and deactivation Avi Kivity
2010-01-06 0:25 ` Marcelo Tosatti
2010-01-06 3:18 ` Avi Kivity
2010-01-06 6:21 ` Avi Kivity
2010-01-06 10:47 ` Joerg Roedel
2010-01-06 11:00 ` Avi Kivity
2010-01-14 13:11 ` Avi Kivity
2010-01-14 13:11 ` Avi Kivity [this message]
2010-01-14 14:34 ` Lucas Meneghel Rodrigues
2010-01-14 15:04 ` Avi Kivity
2009-12-30 16:25 ` [PATCH 5/5] KVM: VMX: Give the guest ownership of cr0.ts when the fpu is active Avi Kivity
2010-01-06 0:40 ` Marcelo Tosatti
2009-12-31 9:23 ` [PATCH 0/5] Lazy fpu, cr0.ts Sheng Yang
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=4B4F1819.7040105@redhat.com \
--to=avi@redhat.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=lmr@redhat.com \
--cc=mtosatti@redhat.com \
--cc=sheng@linux.intel.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 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).