From: Sheng Yang <sheng@linux.intel.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [patch 0/4] use smp_send_reschedule in vcpu_kick / assigned dev host intx race fix
Date: Wed, 6 May 2009 13:07:55 +0800 [thread overview]
Message-ID: <200905061307.56202.sheng@linux.intel.com> (raw)
In-Reply-To: <200904300959.57479.sheng@linux.intel.com>
On Thursday 30 April 2009 09:59:56 Sheng Yang wrote:
> On Thursday 30 April 2009 08:56:57 Sheng Yang wrote:
> > On Thursday 30 April 2009 01:47:57 Marcelo Tosatti wrote:
> > > On Tue, Apr 28, 2009 at 03:08:46PM +0800, Sheng Yang wrote:
> > > > Ack all. This also solved one bug by my hand. Thanks!
> > > >
> > > > I observe one point: the performance of high workload interrupt(e.g.
> > > > 10 gigabyte oplin card) dropped dramatically with
> > > > smp_send_reschedule() method... In one environment(the speed of oplin
> > > > card also limited by cpu performance), Using
> > > > smp_call_function_single() can get more than 1G bit/s stably(native
> > > > got 1.2G), but smp_send_reschedule() can only got around 600M
> > > > bit/s... And the rescheduling interrupt number is about 2000/second
> > > > per cpu. And the interrupt rate is about tens of thousands per second
> > > > for the device.
> > > >
> > > > Anyway, this method is more elegant and correct. Though there is
> > > > still room for optimize - but of course, the correctness is first
> > > > priority.
> > >
> > > Are you using the compat code or a kvm.git kernel? Can you remove only
> > > the last patch (the spinlock) to confirm its the cause of the slowdown?
> >
> > I am using kvm.git.
> >
> > I said this because I tried the old version of patch(which have warning)
> > and it would got more than 1G/sec.
> >
> > I'd like to take a close look at what's happened.
>
> Still ACK this patchset.
>
> And sorry, my memory messed...
>
> The old version of patch and this one offered the same performance. So the
> problem is not here.
>
> I get more than 1g per second by one of myself's experiment.
>
> Disable/enable irq purposed to use with level interrupt to prevent it send
> interrupt again after kernel handler return, but it not applied to
> MSI/MSI-X. Though some interrupt may be merged with one, but AFAIK the
> driver can handle it well.
>
> My experiment is discard disable/enable IRQ for MSI/MSI-X, then can get
> much better performance for oplin card, 2x with disable/enable one.
>
> I would prepare a patch for it.
Hi Avi
Is there any issue blocked this patchset?
Thanks!
--
regards
Yang, Sheng
next prev parent reply other threads:[~2009-05-06 5:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 21:07 [patch 0/4] use smp_send_reschedule in vcpu_kick / assigned dev host intx race fix mtosatti
2009-04-27 21:07 ` [patch 1/4] qemu: external module: smp_send_reschedule compat mtosatti
2009-05-07 13:28 ` Avi Kivity
2009-04-27 21:07 ` [patch 2/4] KVM: x86: wake up waitqueue before calling get_cpu() mtosatti
2009-04-27 21:07 ` [patch 3/4] KVM: use smp_send_reschedule in kvm_vcpu_kick mtosatti
2009-04-27 21:07 ` [patch 4/4] KVM: protect assigned dev workqueue, int handler and irq acker mtosatti
2009-04-28 7:08 ` [patch 0/4] use smp_send_reschedule in vcpu_kick / assigned dev host intx race fix Sheng Yang
2009-04-29 17:47 ` Marcelo Tosatti
2009-04-30 0:56 ` Sheng Yang
2009-04-30 1:59 ` Sheng Yang
2009-05-06 5:07 ` Sheng Yang [this message]
2009-05-07 13:21 ` Avi Kivity
2009-05-07 20:55 ` [patch 0/4] smp_send_reschedule / assigned dev host intx race v2 mtosatti
2009-05-07 20:55 ` [patch 1/4] kvm-kmod: nr_cpu_ids compat mtosatti
2009-05-07 20:55 ` [patch 2/4] kvm-kmod: smp_send_reschedule compat mtosatti
2009-05-07 20:55 ` [patch 3/4] KVM: use smp_send_reschedule in kvm_vcpu_kick mtosatti
2009-05-08 7:13 ` Gleb Natapov
2009-05-07 20:55 ` [patch 4/4] KVM: protect assigned dev workqueue, int handler and irq acker mtosatti
2009-05-10 16:31 ` [patch 0/4] smp_send_reschedule / assigned dev host intx race v2 Avi Kivity
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=200905061307.56202.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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