From: Peter Lieven <pl@kamp.de>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: ronniesahlberg@gmail.com, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-2.4 05/10] block/iscsi: optimize WRITE10/16 if cache.writeback is not set
Date: Thu, 16 Apr 2015 15:02:21 +0200 [thread overview]
Message-ID: <552FB2DD.9010902@kamp.de> (raw)
In-Reply-To: <552FAE53.7050102@redhat.com>
Am 16.04.2015 um 14:42 schrieb Paolo Bonzini:
>
> On 16/04/2015 14:18, Peter Lieven wrote:
>> SCSI allowes to tell the target to not return from a write command
>> if the date is not written to the disk. Use this so called FUA
>> bit if it is supported to optimize WRITE commands if writeback is
>> not allowed.
>>
>> In this case qemu always issues a WRITE followed by a FLUSH. This
>> is 2 round trip times. If we set the FUA bit we can ignore the
>> following FLUSH.
>>
>> Signed-off-by: Peter Lieven <pl@kamp.de>
>> ---
>> block/iscsi.c | 15 +++++++++++++--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/iscsi.c b/block/iscsi.c
>> index 237faa1..7fb04d7 100644
>> --- a/block/iscsi.c
>> +++ b/block/iscsi.c
>> @@ -68,6 +68,7 @@ typedef struct IscsiLun {
>> bool lbprz;
>> bool dpofua;
>> bool has_write_same;
>> + bool force_next_flush;
>> } IscsiLun;
>>
>> typedef struct IscsiTask {
>> @@ -370,6 +371,7 @@ static int coroutine_fn iscsi_co_writev(BlockDriverState *bs,
>> struct IscsiTask iTask;
>> uint64_t lba;
>> uint32_t num_sectors;
>> + int fua = iscsilun->dpofua && !bs->enable_write_cache;
>>
>> if (!is_request_lun_aligned(sector_num, nb_sectors, iscsilun)) {
>> return -EINVAL;
>> @@ -388,12 +390,12 @@ retry:
>> if (iscsilun->use_16_for_rw) {
>> iTask.task = iscsi_write16_task(iscsilun->iscsi, iscsilun->lun, lba,
>> NULL, num_sectors * iscsilun->block_size,
>> - iscsilun->block_size, 0, 0, 0, 0, 0,
>> + iscsilun->block_size, 0, 0, fua, 0, 0,
>> iscsi_co_generic_cb, &iTask);
>> } else {
>> iTask.task = iscsi_write10_task(iscsilun->iscsi, iscsilun->lun, lba,
>> NULL, num_sectors * iscsilun->block_size,
>> - iscsilun->block_size, 0, 0, 0, 0, 0,
>> + iscsilun->block_size, 0, 0, fua, 0, 0,
>> iscsi_co_generic_cb, &iTask);
>> }
>> if (iTask.task == NULL) {
>> @@ -621,6 +623,11 @@ static int coroutine_fn iscsi_co_flush(BlockDriverState *bs)
>> return 0;
>> }
>>
>> + if (iscsilun->dpofua && !bs->enable_write_cache &&
>> + !iscsilun->force_next_flush) {
>> + return 0;
>> + }
>> +
>> iscsi_co_init_iscsitask(iscsilun, &iTask);
>>
>> retry:
>> @@ -648,6 +655,8 @@ retry:
>> return -EIO;
>> }
>>
>> + iscsilun->force_next_flush = false;
> You still need a flush if you do WRITE SAME, WRITE+FUA, WRITE+FUA.
> Also, since bs->enable_write_cache can be toggled arbitrarily, I would
> prefer to set force_next_flush on all non-FUA writes, including those
> done with bs->enable_write_cache.
Good idea. So we can avoid flushes if there was never a write before.
>
>> return 0;
>> }
>>
>> @@ -969,6 +978,8 @@ retry:
>> iscsi_allocationmap_set(iscsilun, sector_num, nb_sectors);
>> }
>>
>> + iscsilun->force_next_flush = true;
> Also, I think it is iscsi_co_generic_cb that should set
> force_next_flush, so that it is only set on failure. Not really for the
> optimization value, but because it's clearer.
I don't get what you mean with it should only "set on failure".
My approach would be to add a flag to the iTask that the command
requires to set force_flush after successful completion. Is it that
what you mean?
>
> I think that if you do these changes, iscsi_co_flush can just check "if
> (!iscsilun->force_next_flush)".
>
> But still---nice approach. :)
Thanks :-)
Peter
next prev parent reply other threads:[~2015-04-16 13:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 12:18 [Qemu-devel] [PATCH for-2.4 00/10] various improvements for the iSCSI driver Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 01/10] block/iscsi: do not forget to logout from target Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 02/10] block/iscsi: change all iscsilun properties from uint8_t to bool Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 03/10] block/iscsi: rename iscsi_write_protected and let it return void Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 04/10] block/iscsi: store DPOFUA bit from the modesense command Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 05/10] block/iscsi: optimize WRITE10/16 if cache.writeback is not set Peter Lieven
2015-04-16 12:42 ` Paolo Bonzini
2015-04-16 13:02 ` Peter Lieven [this message]
2015-04-16 13:17 ` Paolo Bonzini
2015-04-17 7:14 ` Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 06/10] block/iscsi: increase retry count Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 07/10] block/iscsi: bump libiscsi requirement to 1.10.0 Peter Lieven
2015-04-16 12:33 ` Paolo Bonzini
2015-04-16 12:58 ` Peter Lieven
2015-04-16 13:20 ` Paolo Bonzini
2015-04-17 7:16 ` Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 08/10] block/iscsi: handle SCSI_STATUS_TASK_SET_FULL Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 09/10] block/iscsi: bump year in copyright notice Peter Lieven
2015-04-16 12:18 ` [Qemu-devel] [PATCH for-2.4 10/10] block/iscsi: use the allocationmap also if cache.direct=on Peter Lieven
2015-04-16 12:52 ` [Qemu-devel] [PATCH for-2.4 00/10] various improvements for the iSCSI driver Paolo Bonzini
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=552FB2DD.9010902@kamp.de \
--to=pl@kamp.de \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).