Any progress on these patches?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 10, 2011 at 09:18:01AM -0400, Christoph Hellwig wrote:
Any progress on these patches?
Khoa ran ffsb benchmarks on his rig and we didn't see any benefit. I
have not started investigating yet, been working on other things.
It will be necessary to compare against the old patches which
On Mon, Jun 20, 2011 at 4:27 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Sun, Jun 19, 2011 at 8:14 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the
On Sun, Jun 19, 2011 at 8:14 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.
This patch modifies virtqueue_kick() to
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.
As you point out the problem with dropping
On Sun, Jun 19, 2011 at 10:48:41AM +0300, Michael S. Tsirkin wrote:
diff --git a/block/blk-core.c b/block/blk-core.c
index 4ce953f..a8672ec 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -433,6 +433,8 @@ void blk_run_queue(struct request_queue *q)
On Mon, Jun 28, 2010 at 4:55 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and
On 06/29/2010 10:08 AM, Stefan Hajnoczi wrote:
Is it incorrect to have the following pattern?
spin_lock_irqsave(q-queue_lock);
spin_unlock(q-queue_lock);
spin_lock(q-queue_lock);
spin_unlock_irqrestore(q-queue_lock);
Perfectly legitimate. spin_lock_irqsave() is equivalent to
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.
This patch modifies virtqueue_kick() to
On Fri, Jun 25, 2010 at 4:09 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick()
On Fri, Jun 25, 2010 at 12:39:21PM +0930, Rusty Russell wrote:
On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick() and
On Fri, Jun 25, 2010 at 01:43:17PM +0300, Michael S. Tsirkin wrote:
On Fri, Jun 25, 2010 at 12:39:21PM +0930, Rusty Russell wrote:
On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Shouldn't it be
On Fri, Jun 25, 2010 at 04:31:44PM +0100, Stefan Hajnoczi wrote:
On Fri, Jun 25, 2010 at 01:43:17PM +0300, Michael S. Tsirkin wrote:
On Fri, Jun 25, 2010 at 12:39:21PM +0930, Rusty Russell wrote:
On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
On Wed, Jun 23, 2010 at 11:12 PM,
On Fri, Jun 25, 2010 at 06:32:20PM +0300, Michael S. Tsirkin wrote:
On Fri, Jun 25, 2010 at 04:31:44PM +0100, Stefan Hajnoczi wrote:
On Fri, Jun 25, 2010 at 01:43:17PM +0300, Michael S. Tsirkin wrote:
On Fri, Jun 25, 2010 at 12:39:21PM +0930, Rusty Russell wrote:
On Thu, 24 Jun 2010
On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick() and reacquire it afterwards? There's nothing in that
virtqueue_kick() path
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.
This patch modifies virtqueue_kick() to optionally release a lock while
notifying the host. Virtio block is
On 06/23/2010 04:24 PM, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.
This patch modifies virtqueue_kick() to optionally release a
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick() and reacquire it afterwards? There's nothing in that
virtqueue_kick() path that the lock is protecting AFAICT.
No, that would lead to
19 matches
Mail list logo
