qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).