Messages in this thread | | | Date | Wed, 30 Oct 2013 16:51:24 +0800 | From | Asias He <> | Subject | Re: [PATCH 2/2] virtio_blk: blk-mq support |
| |
Hello Jens,
On Tue, Oct 29, 2013 at 03:34:01PM -0600, Jens Axboe wrote: > On 10/28/2013 02:52 AM, Christoph Hellwig wrote: > > On Mon, Oct 28, 2013 at 01:17:54PM +1030, Rusty Russell wrote: > >> Let's pretend I'm stupid. > >> > >> We don't actually have multiple queues through to the host, but we're > >> pretending to, because it makes the block layer go faster? > >> > >> Do I want to know *why* it's faster? Or should I look the other way? > > > > You shouldn't. To how multiple queues benefit here I'd like to defer to > > Jens, given the single workqueue I don't really know where to look here. > > The 4 was chosen to "have some number of multiple queues" and to be able > to exercise that part, no real performance testing was done by me after > the implementation to verify whether it was faster at 1, 2, 4, or > others. But it was useful for that! For merging, we can easily just make > it 1 since that's the most logical transformation. I can set some time > aside to play with multiple queues and see if we gain anything, but that > can be done post merge. > > > The real benefit that unfortunately wasn't obvious from the description > > is that even with just a single queue the blk-multiqueue infrastructure > > will be a lot faster, because it is designed in a much more streaminline > > fashion and avoids lots of lock roundtrips both during submission itself > > and for submission vs complettion. Back when I tried to get virtio-blk > > to perform well on high-end flash (the work that Asias took over later) > > the queue_lock contention was the major issue in virtio-blk and this > > patch gets rid of that even with a single queue. > > > > A good example are the patches from Nick to move scsi drivers over to > > the infrastructure that only support a single queue. Even that gave > > over a 10 fold improvement over the old code. > > > > Unfortunately I do not have access to this kind of hardware at the > > moment, but I'd love to see if Asias or anyone at Red Hat could redo > > those old numbers. > > I've got a variety of fast devices, so should be able to run that. > Asias, let me know what your position is, it'd be great to have > independent results.
I'd love to run the test but I do not have fast devices around. It would be nice if Nick can give a try ;-)
1) Set .nr_hw_queues to 1 instead 4 for now. 2) Drop some more unused code in the other mail I sent
Otherwise, feel free to add:
Acked-by: Asias He <asias@redhat.com>
> -- > Jens Axboe >
-- Asias
| |