All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: linux-kernel@vger.kernel.org, target-devel@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 0/3] target: try satisfying memory requests with higher-order allocations
Date: Thu, 06 Sep 2012 11:04:39 +0200	[thread overview]
Message-ID: <50486727.7060509@redhat.com> (raw)
In-Reply-To: <1346896698.4162.403.camel@haakon2.linux-iscsi.org>

Il 06/09/2012 03:58, Nicholas A. Bellinger ha scritto:
>> This patch series fixes this problem by using higher-order allocations
>> to build the data scatterlist.  The problem is that iscsi assumes that the
>> scatterlist consists of single pages, which is not true anymore.  So
>> patch 2 has to introduce some relatively complicated changes to
>> iscsi_map_iovec and iscsi_unmap_iovec.
> 
> So enabling multi-page per SGL support is a feature that has been
> dormant within target core for a long time.  It's about time that we
> start taking advantage of it again.  ;)

Yeah, I noticed some preparation for it in tcm_fc/tfc_io.c, though too
late (they look a lot like my iscsi changes, it would have saved me some
time!).

While this is obviously not to be taken lightly, I disagree with making
this a per-fabric choice.  With a properly organized (and bisectable)
series, it should be relatively easy to review and to get right.  I
looked a bit more closely now and there are no changes needed to other
targets (actually there is a change needed in tcm_qla2xxx, but the code
is currently disabled).

There are however changes to transport_kmap_data_sg needed and a few
other places.

I definitely agree with your other comments, including making max_order
a DEF_DEV_ATTRIB.  In addition, the default max_order should be capped
based on queue_max_sectors(q) if applicable, to avoid hitting this scenario:

       /*
        * XXX: if the length the device accepts is shorter than the
        *      length of the S/G list entry this will cause and
        *      endless loop.  Better hope no driver uses huge pages.
        */

Paolo

>> While doing this, I noticed something strange in iscsit_do_crypto_hash_sg.
>> Patch 1 adds a warning about it.
>>
> 
> Mmmmm, looks like a separate bug with DataDigest enabled.  
> 
>> The approach may be completely wrong and it needs more testing anyway.
>> Please review!
>>
> 
> Adding my comments inline.
> 
> Thanks Paolo!
> 
> --nab
> 
>> Paolo
>>
>> Paolo Bonzini (3):
>>   tcm_iscsi: warn on incorrect precondition for iscsit_do_crypto_hash_sg
>>   tcm_iscsi: support multiple sizes in the scatterlist
>>   target: try satisfying memory requests with contiguous blocks
>>
>>  drivers/target/iscsi/iscsi_target.c      |  106 +++++++++++++++++++++++++-----
>>  drivers/target/iscsi/iscsi_target_core.h |    2 +-
>>  drivers/target/target_core_transport.c   |   58 ++++++++++++++---
>>  3 files changed, 138 insertions(+), 28 deletions(-)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe target-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


  reply	other threads:[~2012-09-06  9:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05 15:13 [RFC PATCH 0/3] target: try satisfying memory requests with higher-order allocations Paolo Bonzini
2012-09-05 15:13 ` [RFC PATCH 1/3] tcm_iscsi: warn on incorrect precondition for iscsit_do_crypto_hash_sg Paolo Bonzini
2012-09-05 15:13 ` [RFC PATCH 2/3] tcm_iscsi: support multiple sizes in the scatterlist Paolo Bonzini
2012-09-06  2:33   ` Nicholas A. Bellinger
2012-09-05 15:13 ` [RFC PATCH 3/3] target: try satisfying memory requests with contiguous blocks Paolo Bonzini
2012-09-06  2:19   ` Nicholas A. Bellinger
2012-09-06  1:58 ` [RFC PATCH 0/3] target: try satisfying memory requests with higher-order allocations Nicholas A. Bellinger
2012-09-06  9:04   ` Paolo Bonzini [this message]
2012-09-06 18:52     ` Nicholas A. Bellinger
2012-09-06 20:49       ` 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=50486727.7060509@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@vger.kernel.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: link
Be 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.