search for: blk_run_queu

...randommap ioscheduler=noop thread bs=512 size=4MB direct=1 filename=/dev/vdb numjobs=256 ioengine=aio iodepth=64 loops=3 Signed-off-by: Stefan Hajnoczi <stefanha at linux.vnet.ibm.com> --- Other block drivers (cciss, rbd, nbd) use spin_unlock_irq() so I followed that. To me this seems wrong: blk_run_queue() uses spin_lock_irqsave() but we enable irqs with spin_unlock_irq(). If the caller of blk_run_queue() had irqs disabled and we enable them again this could be a problem, right? Can someone more familiar with kernel locking comment? drivers/block/virtio_blk.c | 10 ++++++++-- 1 file changed,...

...randommap ioscheduler=noop thread bs=512 size=4MB direct=1 filename=/dev/vdb numjobs=256 ioengine=aio iodepth=64 loops=3 Signed-off-by: Stefan Hajnoczi <stefanha at linux.vnet.ibm.com> --- Other block drivers (cciss, rbd, nbd) use spin_unlock_irq() so I followed that. To me this seems wrong: blk_run_queue() uses spin_lock_irqsave() but we enable irqs with spin_unlock_irq(). If the caller of blk_run_queue() had irqs disabled and we enable them again this could be a problem, right? Can someone more familiar with kernel locking comment? drivers/block/virtio_blk.c | 10 ++++++++-- 1 file changed,...

...ibata:ata_scsi_queuecmd+0x1b4/0x1d4 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd Apr 18 01:10:00 xenmaster kernel: [<ffffffff880782d0>] :scsi_mod:scsi_io_completio...

...te+0x140/0x16d [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 [<ffffffff88078565>] :...

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 modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent

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 modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent

...) -1; INIT_HLIST_NODE(&rq->hash); RB_CLEAR_NODE(&rq->rb_node); rq->cmd = rq->__cmd; rq->cmd_len = BLK_MAX_CDB; rq->tag = -1; rq->ref_count = 1; rq->start_time = jiffies; set_start_time_ns(rq); @@ -294,18 +294,20 @@ EXPORT_SYMBOL(blk_sync_queue); * __blk_run_queue - run a single device queue * @q: The queue to run * * Description: * See @blk_run_queue. This variant must be called with the queue lock * held and interrupts disabled. */ void __blk_run_queue(struct request_queue *q) { + lockdep_assert_held(q->queue_lock); + if (unlikely...

...) -1; INIT_HLIST_NODE(&rq->hash); RB_CLEAR_NODE(&rq->rb_node); rq->cmd = rq->__cmd; rq->cmd_len = BLK_MAX_CDB; rq->tag = -1; rq->ref_count = 1; rq->start_time = jiffies; set_start_time_ns(rq); @@ -294,18 +294,20 @@ EXPORT_SYMBOL(blk_sync_queue); * __blk_run_queue - run a single device queue * @q: The queue to run * * Description: * See @blk_run_queue. This variant must be called with the queue lock * held and interrupts disabled. */ void __blk_run_queue(struct request_queue *q) { + lockdep_assert_held(q->queue_lock); + if (unlikely...

...struct bio *bio) +diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h +index 860e7a4..45c007d 100644 +--- a/include/linux/blkdev.h ++++ b/include/linux/blkdev.h +@@ -608,10 +608,11 @@ extern void blk_sync_queue(struct reques + extern void __blk_stop_queue(request_queue_t *q); + extern void blk_run_queue(request_queue_t *); + extern void blk_queue_activity_fn(request_queue_t *, activity_fn *, void *); +-extern int blk_rq_map_user(request_queue_t *, struct request *, void __user *, unsigned int); +-extern int blk_rq_unmap_user(struct bio *, unsigned int); ++extern int blk_rq_map_user(request_queue_...

Hi, i have big trouble with a Debian Lenny dom0 and latest kernel 2.6.32.19 with xen-4.0.1rc5. Due some reason the system freezes from time to time. I used kernel 2.6.31.9 with xen-3.4.2 before. The machine doesn''t write anything to serial console so there are no errors or something like that. Perhaps there is something to see from the logs ... Hardware Board: Intel DQ45CB CPU: