similar to: [PATCH net] virtio-net: correctly enable multiqueue

We use single queue even if multiqueue is enabled and let admin to enable it through ethtool later. This is used to avoid possible regression (small packet TCP stream transmission). But looks like an overkill since: - single queue user can disable multiqueue when launching qemu - brings extra troubles for the management since it needs extra admin tool in guest to enable multiqueue - multiqueue

We use single queue even if multiqueue is enabled and let admin to enable it through ethtool later. This is used to avoid possible regression (small packet TCP stream transmission). But looks like an overkill since: - single queue user can disable multiqueue when launching qemu - brings extra troubles for the management since it needs extra admin tool in guest to enable multiqueue - multiqueue

All, just having spotted the backport of Linux commit 03bbcb2e I notice a certain discrepancy with the Xen commit having the same purpose as well as with the actual specification updates: The Linux solution keys off of device IDs 3403 and 3406, as listed in the specification update, but this way fails to cover the X58 chipset, which has - under different numbers (62 and 69) - the same errata

There's a new set of ext2/3 patches for 2.4.21-pre5 available at: http://thunk.org/tytso/linux/extfs-2.4-update/extfs-update-2.4.21pre5-2 and in broken out form at: http://thunk.org/tytso/linux/extfs-2.4-update/broken-out-2.4.21pre5-2 New to this patch set include: * A kludge to help htree work well with Linux's NFS implementation * Allow the orlov allocator to be disabled via a

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Fri, 25 Nov 2016 06:43:08 +0200 > On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote: >> We use single queue even if multiqueue is enabled and let admin to >> enable it through ethtool later. This is used to avoid possible >> regression (small packet TCP stream transmission). But looks like an

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Fri, 25 Nov 2016 06:43:08 +0200 > On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote: >> We use single queue even if multiqueue is enabled and let admin to >> enable it through ethtool later. This is used to avoid possible >> regression (small packet TCP stream transmission). But looks like an

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

I've backported all of the bugfixes to the 2.5 dxdir/htree patches to 2.4, and have created a new set of patches for Linux 2.4.21rc5. At this point it *looks* like we've fixed all of the htree bugs that people have reported, including the brelse bug, the memory leak bugs, and the NFS compatibility problems. I've done *very* light testing, and things seem to work, but I'm now

Hi there, Is there a utility to create an EXT3 file system image from directories? Just like the mkfs.jffs2 which creates a JFFS2 file system image from directories? The "mke2fs -j" only creates the bare bone file system, what I want is to build an image with pre-built content. Thanks, Debbie

On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > > There is a huge disadvantage to the fact that CPUID is a user space > instruction, though. But if the goal is to provide something like getrandom(2) direct from the Host OS, it's not necessarily harmful to allow the Guest ring 3 code to be able to fetch randomness in that way. The hypervisor can implement rate

On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > > There is a huge disadvantage to the fact that CPUID is a user space > instruction, though. But if the goal is to provide something like getrandom(2) direct from the Host OS, it's not necessarily harmful to allow the Guest ring 3 code to be able to fetch randomness in that way. The hypervisor can implement rate

On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote: > We use single queue even if multiqueue is enabled and let admin to > enable it through ethtool later. This is used to avoid possible > regression (small packet TCP stream transmission). But looks like an > overkill since: > > - single queue user can disable multiqueue when launching qemu > - brings extra troubles

https://bugzilla.samba.org/show_bug.cgi?id=11588 Bug ID: 11588 Summary: missing option: preallocate for all files except for sparse Product: rsync Version: 3.1.2 Hardware: x64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: core

On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote: > > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > >> > >> There is a huge disadvantage to the fact that CPUID is a user space > >> instruction, though. > > > > But if the goal is to

On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote: > > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > >> > >> There is a huge disadvantage to the fact that CPUID is a user space > >> instruction, though. > > > > But if the goal is to

On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote: > > It's head of my virtio-next tree. Hey Rusty, While we have your attention --- what's your opinion about adding TRIM support to virtio-blk. I understand that you're starting an OASIS standardization process for virtio --- what does that mean vis-a-vis a patch to plumb discard support through virtio-blk?

On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote: > > It's head of my virtio-next tree. Hey Rusty, While we have your attention --- what's your opinion about adding TRIM support to virtio-blk. I understand that you're starting an OASIS standardization process for virtio --- what does that mean vis-a-vis a patch to plumb discard support through virtio-blk?