search for: total_in

...to the queue. */ static inline int vring_add_indirect(struct vring_virtqueue *vq, struct scatterlist *sgs[], - struct scatterlist *(*next) - (struct scatterlist *, unsigned int *), unsigned int total_sg, unsigned int total_out, unsigned int total_in, @@ -128,7 +112,7 @@ static inline int vring_add_indirect(struct vring_virtqueue *vq, struct vring_desc *desc; unsigned head; struct scatterlist *sg; - int i, n; + int i, j, n; /* * We require lowmem mappings for the descriptors because @@ -144,7 +128,9 @@ static inline int vring_add_i...

...to the queue. */ static inline int vring_add_indirect(struct vring_virtqueue *vq, struct scatterlist *sgs[], - struct scatterlist *(*next) - (struct scatterlist *, unsigned int *), unsigned int total_sg, - unsigned int total_out, - unsigned int total_in, unsigned int out_sgs, unsigned int in_sgs, gfp_t gfp) @@ -144,7 +126,7 @@ static inline int vring_add_indirect(struct vring_virtqueue *vq, /* Transfer entries from the sg lists into the indirect page */ i = 0; for (n = 0; n < out_sgs; n++) { - for (sg = sgs[...

...ma is relevant. I tried -net user a -net tap >> with iperf running in both directions. I also tried switching >> virtio_pci into non-DMA-API mode. No errors. >> >> Is there any chance that you could instrument that BUG_ON to print n, >> i, in_sgs, out_sgs, total_sg, total_in, and total_out? I assume this >> is some oddity with patch 1, but I'm mystified. > > Yes, its triggered by patch 1. I must be doing something wrong, since virtio_net isn't sending me through that code path at all. This may be related to ethtool refusing to enable scatter-gath...

...ma is relevant. I tried -net user a -net tap >> with iperf running in both directions. I also tried switching >> virtio_pci into non-DMA-API mode. No errors. >> >> Is there any chance that you could instrument that BUG_ON to print n, >> i, in_sgs, out_sgs, total_sg, total_in, and total_out? I assume this >> is some oddity with patch 1, but I'm mystified. > > Yes, its triggered by patch 1. I must be doing something wrong, since virtio_net isn't sending me through that code path at all. This may be related to ethtool refusing to enable scatter-gath...

...to the queue. */ static inline int vring_add_indirect(struct vring_virtqueue *vq, struct scatterlist *sgs[], - struct scatterlist *(*next) - (struct scatterlist *, unsigned int *), unsigned int total_sg, - unsigned int total_out, - unsigned int total_in, unsigned int out_sgs, unsigned int in_sgs, gfp_t gfp) @@ -155,7 +137,7 @@ static inline int vring_add_indirect(struct vring_virtqueue *vq, /* Transfer entries from the sg lists into the indirect page */ i = 0; for (n = 0; n < out_sgs; n++) { - for (sg = sgs[...

...to the queue. */ static inline int vring_add_indirect(struct vring_virtqueue *vq, struct scatterlist *sgs[], - struct scatterlist *(*next) - (struct scatterlist *, unsigned int *), unsigned int total_sg, - unsigned int total_out, - unsigned int total_in, unsigned int out_sgs, unsigned int in_sgs, gfp_t gfp) @@ -155,7 +137,7 @@ static inline int vring_add_indirect(struct vring_virtqueue *vq, /* Transfer entries from the sg lists into the indirect page */ i = 0; for (n = 0; n < out_sgs; n++) { - for (sg = sgs[...

...n x86_64 on KVM. I doubt that dma vs. non-dma is relevant. I tried -net user a -net tap with iperf running in both directions. I also tried switching virtio_pci into non-DMA-API mode. No errors. Is there any chance that you could instrument that BUG_ON to print n, i, in_sgs, out_sgs, total_sg, total_in, and total_out? I assume this is some oddity with patch 1, but I'm mystified. Thanks, Andy > > [ 8.643981] ------------[ cut here ]------------ > [ 8.643986] kernel BUG at drivers/virtio/virtio_ring.c:245! > [ 8.644036] illegal operation: 0001 [#1] SMP > [ 8.644039...

...n x86_64 on KVM. I doubt that dma vs. non-dma is relevant. I tried -net user a -net tap with iperf running in both directions. I also tried switching virtio_pci into non-DMA-API mode. No errors. Is there any chance that you could instrument that BUG_ON to print n, i, in_sgs, out_sgs, total_sg, total_in, and total_out? I assume this is some oddity with patch 1, but I'm mystified. Thanks, Andy > > [ 8.643981] ------------[ cut here ]------------ > [ 8.643986] kernel BUG at drivers/virtio/virtio_ring.c:245! > [ 8.644036] illegal operation: 0001 [#1] SMP > [ 8.644039...

I resurrected these patches after prompting from Andy Lutomirski's recent patches. I put them on the back-burner because vring_bench had a 15% slowdown on my laptop: pktgen testing revealed a speedup, if anything, so I've cleaned them up. Rusty Russell (3): virtio_net: pass well-formed sgs to virtqueue_add_*() virtio_ring: assume sgs are always well-formed. virtio_ring: unify

I resurrected these patches after prompting from Andy Lutomirski's recent patches. I put them on the back-burner because vring_bench had a 15% slowdown on my laptop: pktgen testing revealed a speedup, if anything, so I've cleaned them up. Rusty Russell (3): virtio_net: pass well-formed sgs to virtqueue_add_*() virtio_ring: assume sgs are always well-formed. virtio_ring: unify

This fixes virtio on Xen guests as well as on any other platform on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches, everything works. There

This fixes virtio on Xen guests as well as on any other platform on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches, everything works. There

...net user a -net tap >> > with iperf running in both directions. I also tried switching >> > virtio_pci into non-DMA-API mode. No errors. >> > >> > Is there any chance that you could instrument that BUG_ON to print n, >> > i, in_sgs, out_sgs, total_sg, total_in, and total_out? I assume this >> > is some oddity with patch 1, but I'm mystified. > Yes, its triggered by patch 1. What version of QEMU? Can you two cat the "features" file in the virtio-net device's sysfs directory? Paolo

...net user a -net tap >> > with iperf running in both directions. I also tried switching >> > virtio_pci into non-DMA-API mode. No errors. >> > >> > Is there any chance that you could instrument that BUG_ON to print n, >> > i, in_sgs, out_sgs, total_sg, total_in, and total_out? I assume this >> > is some oddity with patch 1, but I'm mystified. > Yes, its triggered by patch 1. What version of QEMU? Can you two cat the "features" file in the virtio-net device's sysfs directory? Paolo

...gned long long)logical, (unsigned long long)length, (unsigned long long)map_length); diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c index 92c2065..9acb846 100644 --- a/fs/btrfs/zlib.c +++ b/fs/btrfs/zlib.c @@ -97,7 +97,7 @@ static int zlib_compress_pages(struct list_head *ws, *total_in = 0; if (Z_OK != zlib_deflateInit(&workspace->def_strm, 3)) { - printk(KERN_WARNING "deflateInit failed\n"); + printk(KERN_WARNING "btrfs: deflateInit failed\n"); ret = -1; goto out; } @@ -125,7 +125,7 @@ static int zlib_compress_pages(struct list_head *ws,...

OK, so I've spent a few days benchmarking. Turns out 80% of virtio_add_buf cases are uni-directional (including the always-performance-sensitive networking code), and that gets no performance penalty (though tests with real networking would be appreciated!). I'm not reposting all the "convert driver to virtio_add_outbuf()" patches: just the scsi one which I didn't have

OK, so I've spent a few days benchmarking. Turns out 80% of virtio_add_buf cases are uni-directional (including the always-performance-sensitive networking code), and that gets no performance penalty (though tests with real networking would be appreciated!). I'm not reposting all the "convert driver to virtio_add_outbuf()" patches: just the scsi one which I didn't have

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,