[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [kvm-devel] [PATCH RFC 3/3] virtio infrastructure: example block driver
- To: carsteno@xxxxxxxxxx
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
- Date: Mon, 4 Jun 2007 15:43:23 +0200
- Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "jmk@xxxxxxxxxxxxxxxxxxx" <jmk@xxxxxxxxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, mschwid2@xxxxxxxxxxxxxxxxxx, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>
- Delivery-date: Mon, 04 Jun 2007 09:46:59 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
On Mon, Jun 04 2007, Carsten Otte wrote:
> Jens Axboe wrote:
> >On Fri, Jun 01 2007, Carsten Otte wrote:
> >>With regard to compute power needed, almost none. The penalty is
> >>latency, not overhead: A small request may sit on the request queue to
> >>wait for other work to arrive until the queue gets unplugged. This
> >>penality is compensated by the benefit of a good chance that more
> >>requests will be merged during this time period.
> >>If we have this method both in host and guest, we have twice the
> >>penalty with no added benefit.
> >I don't buy that argument. We can easily expose the unplug delay, so you
> >can kill it at what ever level you want. Or you could just do it in the
> >driver right now, but that is a bit hackish.
> That would be preferable if the device driver can chose the unplug
> delay, or even better it could be (guest)sysfs tuneable.
Right. We probably should make it sysfs configurable in any case, right
now it's a (somewhat) policy decision in the kernel with the delay and
Xen-devel mailing list