Re: KVM with PCI forwarding really slow after 4.1
On Tue, 1 Dec 2015 18:47:51 +0100 Paolo Bonzini <pbonz...@redhat.com> wrote: > On 01/12/2015 18:09, Michael Büsch wrote: > > I use "-device pci-assign,host=00:1a.0" to forward a USB host chip > > to a Win7 32 bit inside of qemu/kvm. That used to work pretty well, > > but it broke horribly somewhere after 4.1. With recent kernels the > > virtual machine boots, but is _very_ slow. It takes hours to boot. > > If PCI forwarding is disabled, everything is fine. > > This has been reported already, I'm going to look at it this week. Are there any news regarding this issue? -- Michael pgpgTbPhOu0gn.pgp Description: OpenPGP digital signature
KVM with PCI forwarding really slow after 4.1
Hi, I use "-device pci-assign,host=00:1a.0" to forward a USB host chip to a Win7 32 bit inside of qemu/kvm. That used to work pretty well, but it broke horribly somewhere after 4.1. With recent kernels the virtual machine boots, but is _very_ slow. It takes hours to boot. If PCI forwarding is disabled, everything is fine. qemu throws this warning on startup: qemu-system-i386: -device pci-assign,host=00:1a.0: PCI region 0 at address 0xf253a000 has size 0x400, which is not a multiple of 4K. You might experience some performance hit due to that. _But_ it also shows that warning for 4.1 and earlier kernels that work pretty fast. I tried to bisect the problem, but I ran into some some kernels that don't even boot on my machine (the skipped ones). So it's a bit hard to make progress. Here is my git bisect log that narrows it down to under 100 commits. Does anyone have a clue what could cause this? (The log can be replayed with git bisect replay on Linus' tree). # bad: [8005c49d9aea74d382f474ce11afbbc7d7130bec] Linux 4.4-rc1 # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 git bisect start 'v4.4-rc1' 'v4.1' # bad: [dd5cdb48edfd34401799056a9acf61078d773f90] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect bad dd5cdb48edfd34401799056a9acf61078d773f90 # bad: [23908db413eccd77084b09c9b0a4451dfb0524c0] Merge tag 'staging-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging git bisect bad 23908db413eccd77084b09c9b0a4451dfb0524c0 # bad: [14738e03312ff1137109d68bcbf103c738af0f4a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect bad 14738e03312ff1137109d68bcbf103c738af0f4a # good: [5a602e157a9d91d5ce98d07c404097edba8ec9f3] Merge tag 'spi-v4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi git bisect good 5a602e157a9d91d5ce98d07c404097edba8ec9f3 # good: [a4244b0cf58d56c171874e85228ba5deffeb017a] net/ethtool: Add current supported tunable options git bisect good a4244b0cf58d56c171874e85228ba5deffeb017a # bad: [98ec21a01896751b673b6c731ca8881daa8b2c6d] Merge branch 'sched-hrtimers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 98ec21a01896751b673b6c731ca8881daa8b2c6d # good: [4b1f2af6752a4cc9acc1c22ddf3842478965f113] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect good 4b1f2af6752a4cc9acc1c22ddf3842478965f113 # good: [08d183e3c1f650b4db1d07d764502116861542fa] Merge tag 'powerpc-4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux git bisect good 08d183e3c1f650b4db1d07d764502116861542fa # skip: [05fe125fa3237de2ec5bada80031e694de78909c] Merge tag 'kvm-arm-for-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD git bisect skip 05fe125fa3237de2ec5bada80031e694de78909c # skip: [edc90b7dc4ceef62ef0ad9cc6c3f5dc770e83ad2] KVM: MMU: fix SMAP virtualization git bisect skip edc90b7dc4ceef62ef0ad9cc6c3f5dc770e83ad2 # skip: [910a6aae4e2e45855efc4a268e43eed2d8445575] KVM: MTRR: exactly define the size of variable MTRRs git bisect skip 910a6aae4e2e45855efc4a268e43eed2d8445575 # skip: [822bf4833ecc8ea63c69f3ed894c13b4509c9e85] arm64: defconfig: enable memtest git bisect skip 822bf4833ecc8ea63c69f3ed894c13b4509c9e85 -- Michael pgpOqF_wEpYeL.pgp Description: OpenPGP digital signature
Re: [PATCH v2 3/3] hw_random: increase schedule timeout in rng_dev_read()
On Tue, 16 Sep 2014 08:27:40 +0800 Amos Kong ak...@redhat.com wrote: Set timeout to 10: non-smp guest with quick backend (1.2M/s) - about 490K/s) That sounds like an awful lot. This is a 60% loss in throughput. I don't think we can live with that. -- Michael signature.asc Description: PGP signature
Re: [PATCH v2 1/3] virtio-rng cleanup: move some code out of mutex protection
On Tue, 16 Sep 2014 00:02:27 +0800
Amos Kong ak...@redhat.com wrote:
It doesn't save too much cpu time as expected, just a cleanup.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25..c591d7e 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -270,8 +270,8 @@ static ssize_t hwrng_attr_current_show(struct device *dev,
return -ERESTARTSYS;
if (current_rng)
name = current_rng-name;
- ret = snprintf(buf, PAGE_SIZE, %s\n, name);
mutex_unlock(rng_mutex);
+ ret = snprintf(buf, PAGE_SIZE, %s\n, name);
I'm not sure this is safe.
Name is just a pointer.
What if the hwrng gets unregistered after unlock and just before the snprintf?
return ret;
}
@@ -284,19 +284,19 @@ static ssize_t hwrng_attr_available_show(struct device
*dev,
ssize_t ret = 0;
struct hwrng *rng;
+ buf[0] = '\0';
err = mutex_lock_interruptible(rng_mutex);
if (err)
return -ERESTARTSYS;
- buf[0] = '\0';
list_for_each_entry(rng, rng_list, list) {
strncat(buf, rng-name, PAGE_SIZE - ret - 1);
ret += strlen(rng-name);
strncat(buf, , PAGE_SIZE - ret - 1);
ret++;
}
+ mutex_unlock(rng_mutex);
strncat(buf, \n, PAGE_SIZE - ret - 1);
ret++;
- mutex_unlock(rng_mutex);
return ret;
}
This looks ok.
--
Michael
signature.asc
Description: PGP signature
Re: [PATCH v2 3/3] hw_random: increase schedule timeout in rng_dev_read()
On Tue, 16 Sep 2014 00:02:29 +0800
Amos Kong ak...@redhat.com wrote:
This patch increases the schedule timeout to 10 jiffies, it's more
appropriate, then other takes can easy to hold the mutex lock.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 263a370..b5d1b6f 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -195,7 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char
__user *buf,
mutex_unlock(rng_mutex);
- schedule_timeout_interruptible(1);
+ schedule_timeout_interruptible(10);
if (signal_pending(current)) {
err = -ERESTARTSYS;
Does a schedule of 1 ms or 10 ms decrease the throughput?
I think we need some benchmarks.
--
Michael
signature.asc
Description: PGP signature
