From: Rusty Russell <rusty@rustcorp.com.au> To: Asias He <asias@redhat.com> Cc: Sasha Levin <levinsasha928@gmail.com>, dlaor@redhat.com, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH 3/3] virtio-blk: Add bio-based IO path for virtio-blk Date: Mon, 02 Jul 2012 16:11:32 +0930 [thread overview] Message-ID: <8762a6y89v.fsf@rustcorp.com.au> (raw) In-Reply-To: <4FF10B31.60609@redhat.com> On Mon, 02 Jul 2012 10:45:05 +0800, Asias He <asias@redhat.com> wrote: > On 07/02/2012 07:54 AM, Rusty Russell wrote: > > Confused. So, without merging we get 6k exits (per second?) How many > > do we get when we use the request-based IO path? > > Sorry for the confusion. The numbers were collected from request-based > IO path where we can have the guest block layer merge the requests. > > With the same workload in guest, the guest fires 200K requests to host > with merges enabled in guest (echo 0 > /sys/block/vdb/queue/nomerges), > while the guest fires 40000K requests to host with merges disabled in > guest (echo 2 > /sys/block/vdb/queue/nomerges). This show that the merge > in block layer reduces the total number of requests fire to host a lot > (40000K / 200K = 20). > > The guest fires 200K requests to host with merges enabled in guest (echo > 0 > /sys/block/vdb/queue/nomerges), the host fires 6K interrupts in > total for the 200K requests. This show that the ratio of interrupts > coalesced (200K / 6K = 33). OK, got it! Guest merging cuts requests by a factor of 20. EVENT_IDX cuts interrupts by a factor of 33. > > If your device is slow, then you won't be able to make many requests per > > second: why worry about exit costs? > > If a device is slow, the merge would merge more requests and reduce the > total number of requests to host. This saves exit costs, no? Sure, our guest merging might save us 100x as many exits as no merging. But since we're not doing many requests, does it matter? Ideally we'd merge requests only if the device queue is full. But that sounds hard. > > If your device is fast (eg. ram), > > you've already shown that your patch is a win, right? > > Yes. Both on ramdisk and fast SSD device (e.g. FusionIO). Thanks, Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au> To: Asias He <asias@redhat.com> Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Sasha Levin <levinsasha928@gmail.com>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH 3/3] virtio-blk: Add bio-based IO path for virtio-blk Date: Mon, 02 Jul 2012 16:11:32 +0930 [thread overview] Message-ID: <8762a6y89v.fsf@rustcorp.com.au> (raw) In-Reply-To: <4FF10B31.60609@redhat.com> On Mon, 02 Jul 2012 10:45:05 +0800, Asias He <asias@redhat.com> wrote: > On 07/02/2012 07:54 AM, Rusty Russell wrote: > > Confused. So, without merging we get 6k exits (per second?) How many > > do we get when we use the request-based IO path? > > Sorry for the confusion. The numbers were collected from request-based > IO path where we can have the guest block layer merge the requests. > > With the same workload in guest, the guest fires 200K requests to host > with merges enabled in guest (echo 0 > /sys/block/vdb/queue/nomerges), > while the guest fires 40000K requests to host with merges disabled in > guest (echo 2 > /sys/block/vdb/queue/nomerges). This show that the merge > in block layer reduces the total number of requests fire to host a lot > (40000K / 200K = 20). > > The guest fires 200K requests to host with merges enabled in guest (echo > 0 > /sys/block/vdb/queue/nomerges), the host fires 6K interrupts in > total for the 200K requests. This show that the ratio of interrupts > coalesced (200K / 6K = 33). OK, got it! Guest merging cuts requests by a factor of 20. EVENT_IDX cuts interrupts by a factor of 33. > > If your device is slow, then you won't be able to make many requests per > > second: why worry about exit costs? > > If a device is slow, the merge would merge more requests and reduce the > total number of requests to host. This saves exit costs, no? Sure, our guest merging might save us 100x as many exits as no merging. But since we're not doing many requests, does it matter? Ideally we'd merge requests only if the device queue is full. But that sounds hard. > > If your device is fast (eg. ram), > > you've already shown that your patch is a win, right? > > Yes. Both on ramdisk and fast SSD device (e.g. FusionIO). Thanks, Rusty.
next prev parent reply other threads:[~2012-07-02 22:52 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-06-18 6:53 [PATCH v2 0/3] Improve virtio-blk performance Asias He 2012-06-18 6:53 ` Asias He 2012-06-18 6:53 ` [PATCH 1/3] block: Introduce __blk_segment_map_sg() helper Asias He 2012-06-18 6:53 ` Asias He 2012-06-18 21:31 ` Tejun Heo 2012-06-18 21:31 ` Tejun Heo 2012-06-19 2:02 ` Asias He 2012-06-19 2:02 ` Asias He 2012-06-19 18:00 ` Tejun Heo 2012-06-19 18:00 ` Tejun Heo 2012-06-18 6:53 ` [PATCH v2 2/3] block: Add blk_bio_map_sg() helper Asias He 2012-06-18 6:53 ` Asias He 2012-06-18 6:53 ` [PATCH 3/3] virtio-blk: Add bio-based IO path for virtio-blk Asias He 2012-06-18 6:53 ` Asias He 2012-06-18 7:46 ` Rusty Russell 2012-06-18 7:46 ` Rusty Russell 2012-06-18 8:03 ` Asias He 2012-06-18 8:03 ` Asias He 2012-06-18 10:05 ` Rusty Russell 2012-06-18 10:05 ` Rusty Russell 2012-06-18 11:14 ` Dor Laor 2012-06-18 11:14 ` Dor Laor 2012-06-18 11:39 ` Sasha Levin 2012-06-18 11:39 ` Sasha Levin 2012-06-19 2:51 ` Asias He 2012-06-19 2:51 ` Asias He 2012-06-19 6:21 ` Dor Laor 2012-06-19 6:21 ` Dor Laor 2012-06-20 4:46 ` Asias He 2012-06-20 4:46 ` Asias He 2012-06-21 9:49 ` Dor Laor 2012-06-21 9:49 ` Dor Laor 2012-07-01 23:54 ` Rusty Russell 2012-07-02 2:45 ` Asias He 2012-07-02 2:45 ` Asias He 2012-07-02 6:41 ` Rusty Russell [this message] 2012-07-02 6:41 ` Rusty Russell 2012-07-03 0:39 ` Asias He 2012-07-03 0:39 ` Asias He 2012-07-04 2:40 ` Rusty Russell 2012-07-04 2:40 ` Rusty Russell 2012-07-06 1:03 ` Asias He 2012-07-06 1:03 ` Asias He 2012-07-03 13:31 ` Paolo Bonzini 2012-07-03 13:31 ` Paolo Bonzini 2012-07-03 14:02 ` Asias He 2012-07-03 14:02 ` Asias He 2012-07-01 23:54 ` Rusty Russell 2012-07-03 14:22 ` Ronen Hod 2012-07-03 14:22 ` Ronen Hod 2012-07-03 14:28 ` Dor Laor 2012-07-03 14:28 ` Dor Laor 2012-07-04 14:10 ` Paolo Bonzini 2012-07-04 14:10 ` Paolo Bonzini 2012-06-18 21:28 ` Tejun Heo 2012-06-18 21:28 ` Tejun Heo 2012-06-19 2:39 ` Asias He 2012-06-19 2:39 ` Asias He 2012-06-18 10:13 ` Michael S. Tsirkin 2012-06-18 10:13 ` Michael S. Tsirkin 2012-06-19 2:21 ` Asias He 2012-06-19 2:21 ` Asias He 2012-06-18 9:37 ` Stefan Hajnoczi 2012-06-18 9:37 ` Stefan Hajnoczi 2012-06-18 10:21 ` Michael S. Tsirkin 2012-06-18 10:21 ` Michael S. Tsirkin 2012-06-18 10:45 ` Stefan Hajnoczi 2012-06-18 10:45 ` Stefan Hajnoczi 2012-06-19 2:30 ` Asias He 2012-06-19 2:30 ` Asias He 2012-06-18 9:14 ` [PATCH v2 0/3] Improve virtio-blk performance Stefan Hajnoczi 2012-06-18 9:14 ` Stefan Hajnoczi 2012-06-18 9:39 ` Asias He 2012-06-18 9:39 ` Asias He 2012-06-18 10:58 ` Stefan Hajnoczi 2012-06-18 10:58 ` Stefan Hajnoczi 2012-06-19 4:24 ` Asias He 2012-06-19 4:24 ` Asias He 2012-06-19 10:14 ` Stefan Hajnoczi 2012-06-19 10:14 ` Stefan Hajnoczi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8762a6y89v.fsf@rustcorp.com.au \ --to=rusty@rustcorp.com.au \ --cc=asias@redhat.com \ --cc=dlaor@redhat.com \ --cc=hch@lst.de \ --cc=kvm@vger.kernel.org \ --cc=levinsasha928@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.