The current virtio block sets a queue depth of 64. With a
sufficiently fast device, using a queue depth of 256 can double the
IOPS which can be sustained. So make the queue depth something which
can be set at module load time or via a kernel boot-time parameter.
Signed-off-by: "Theodore
On Fri, Mar 14, 2014 at 10:38:40AM -0700, Joe Perches wrote:
> > +static int queue_depth = 64;
> > +module_param(queue_depth, int, 444);
>
> 444? Really Ted?
Oops, *blush*. Thanks for catching that.
- Ted
___
, for
testing/benchmarking purposes.
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Venkatesh Srinivas
Cc: Rusty Russell
Cc: "Michael S. Tsirkin"
Cc: virtio-...@lists.oasis-open.org
Cc: virtualization@lists.linux-foundation.org
Cc: Frank Swiderski
---
This is a combinat
On Sat, Mar 15, 2014 at 06:57:01AM -0400, Konrad Rzeszutek Wilk wrote:
> >+pr_info("%s: using queue depth %d\n", vblk->disk->disk_name,
> >+virtio_mq_reg.queue_depth);
>
> Isn't that visible from sysfs?
As near as I can tell, it's not. I haven't been able to find anything
that ei
On Sat, Mar 15, 2014 at 06:57:23AM -0700, Christoph Hellwig wrote:
> I don't think this should be a module parameter. The default sizing
> should be based of the parameters of the actual virtqueue, and if we
> want to allow tuning it it should be by a sysfs attribute, preferable
> using the same s
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 do
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
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 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 use
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
>
> Actually, a much bigger reason is because it lets rogue guest *user
> space*, even will a well-behaved guest OS, do something potentially
> harmful to the host.
Right, but if the host kernel is dependent on the guest OS for
secur
is a bug, since
> based on my previous statement, in this scenario, getrandom should
> never block.
This is correct; and it has been fixed in the patches in v4.8-rc1.
The patch which fixes this has been marked for backporting to stable
kernels:
commit 3371f3da08cff4b75c1f2dce742d460539d6566d
Aut
On Wed, May 11, 2022 at 12:31:16PM -0400, Konstantin Ryabitsev wrote:
> > But my mailer, editor and terminal don't know what to do with a Message-Id.
> >
> > Whereas they can all open an https link.
> >
> > Making people paste message ids into lore to see the original submission
> > is not a win.
tio pmem and ext4.
>
> Signed-off-by: Pankaj Gupta
> Reviewed-by: Jan Kara
Acked-by: Theodore Ts'o
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Thu, Nov 04, 2021 at 12:04:43PM -0700, Darrick J. Wong wrote:
> > Note that I've avoided implementing read/write fops for dax devices
> > partly out of concern for not wanting to figure out shared-mmap vs
> > write coherence issues, but also because of a bet with Dave Hansen
> > that device-dax
13 matches
Mail list logo
