On Thu, Oct 06, 2011 at 12:22:14PM +1030, Rusty Russell wrote: > On Wed, 05 Oct 2011 15:54:08 -0400, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > Add an alternate I/O path that implements ->make_request for virtio-blk. > > This is required for high IOPs devices which get slowed down to 1/5th of > > the native speed by all the locking, memory allocation and other overhead > > in the request based I/O path. > > Ouch. > > I'd be tempted to just switch across to this, though I'd be interested > to see if the simple add_buf change I referred to before has some effect > by itself (I doubt it). Benchmarking this more extensively even on low-end devices is number on my todo list after sorting out the virtqueue race and implementing flush/fua support. I'd really prefer to switch over to it unconditionally if the performance numbers allow it. > Also, though it's overkill I'd use standard list primitives rather than > open-coding a single linked list. I really prefer using standard helpers, but using a doubly linked list and increasing memory usage seems like such a waste. Maybe I should annoy Linus by proposing another iteration of a common single linked list implementation :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
