public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Douglas Gilbert <dgilbert@interlog.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	Daniel Wagner <daniel.wagner@suse.com>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	James Bottomley <james.bottomley@hansenpartnership.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 3/4] scsi: move target device list to xarray
Date: Fri, 29 May 2020 15:17:00 +0200	[thread overview]
Message-ID: <7e9893bb-5445-7d71-205b-e22f256c8796@suse.de> (raw)
In-Reply-To: <20200529125022.GA19604@bombadil.infradead.org>

On 5/29/20 2:50 PM, Matthew Wilcox wrote:
> On Fri, May 29, 2020 at 02:46:48PM +0200, Hannes Reinecke wrote:
>> On 5/29/20 1:21 PM, Matthew Wilcox wrote:
>>> On Fri, May 29, 2020 at 08:50:21AM +0200, Hannes Reinecke wrote:
>>>>> I meant just use xa_alloc() for everything instead of using xa_insert for
>>>>> 0-255.
>>>>>
>>>> But then I'll have to use xa_find() to get to the actual element as the 1:1
>>>> mapping between SCSI LUN and array index is lost.
>>>> And seeing that most storage arrays will expose only up to 256 LUNs I
>>>> thought this was a good improvement on lookup.
>>>> Of course, this only makes sense if xa_load() is more efficient than
>>>> xa_find(). If not then of course it's a bit futile.
>>>
>>> xa_load() is absolutely more efficient than xa_find().  It's just a
>>> question of whether it matters ;-)  Carry on ...
>>>
>> Thanks. I will.
>>
>> BTW, care to update the documentation?
>>
>>   * Return: 0 on success, -ENOMEM if memory could not be allocated or
>>   * -EBUSY if there are no free entries in @limit.
>>   */
>> int __xa_alloc(struct xarray *xa, u32 *id, void *entry,
>> 		struct xa_limit limit, gfp_t gfp)
>> {
>> 	XA_STATE(xas, xa, 0);
>>
>> 	if (WARN_ON_ONCE(xa_is_advanced(entry)))
>> 		return -EINVAL;
>> 	if (WARN_ON_ONCE(!xa_track_free(xa)))
>> 		return -EINVAL;
>>
>> So looks as if the documentation is in need of updating to cover -EINVAL.
>> And, please, state somewhere that whenever you want to use xa_alloc() you
>> _need_ to specify XA_ALLOC_FLAGS in xa_init_flags(), otherwise
>> you trip across the above.
> 
> Like this?
> 
> Allocating XArrays
> ------------------
> 
> If you use DEFINE_XARRAY_ALLOC() to define the XArray, or
> initialise it by passing ``XA_FLAGS_ALLOC`` to xa_init_flags(),
> the XArray changes to track whether entries are in use or not.
> 
> You can call xa_alloc() to store the entry at an unused index
> in the XArray.  If you need to modify the array from interrupt context,
> you can use xa_alloc_bh() or xa_alloc_irq() to disable
> interrupts while allocating the ID.
> 
> 
What I'm missing is the connection between the first paragraph and the 
second.
It starts with 'If you use ...', making no indication what would happen 
if you don't.
And the second paragraph just says '... to store the entry ...'; is 
never said anything about tracking entries.

Why not simply append this sentenct to the second paragraph:

In order to use xa_alloc() you need to pass the XA_FLAGS_ALLOC when
calling xa_init_flags()l

>> It's not entirely obvious, and took me the better half of a day to figure
>> out.
> 
> Really?  You get a nice WARN_ON and backtrace so you can see where
> you went wrong ... What could I change to make this easier?
> 
It _could_ have said 'You forgot to pass XA_ALLOC_FLAGS in xa_init_flags()'.
Then it would've been immediately obvious without having to delve into 
xarray code.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

  reply	other threads:[~2020-05-29 13:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 16:36 [PATCHv3 0/4] scsi: use xarray for devices and targets Hannes Reinecke
2020-05-28 16:36 ` [PATCH 1/4] scsi: convert target lookup to xarray Hannes Reinecke
2020-05-28 17:18   ` Douglas Gilbert
2020-05-28 19:08     ` Douglas Gilbert
2020-05-28 17:48   ` Bart Van Assche
2020-05-29  6:24     ` Hannes Reinecke
2020-05-28 16:36 ` [PATCH 2/4] target_core_pscsi: use __scsi_device_lookup() Hannes Reinecke
2020-05-28 17:55   ` Bart Van Assche
2020-05-29  7:02   ` Daniel Wagner
2020-05-28 16:36 ` [PATCH 3/4] scsi: move target device list to xarray Hannes Reinecke
2020-05-28 17:50   ` Douglas Gilbert
2020-05-28 18:54     ` Matthew Wilcox
2020-05-28 19:44       ` Douglas Gilbert
2020-05-28 19:53         ` Matthew Wilcox
2020-05-29  6:45         ` Hannes Reinecke
2020-05-28 20:58       ` Hannes Reinecke
2020-05-29  0:20         ` Matthew Wilcox
2020-05-29  6:50           ` Hannes Reinecke
2020-05-29 11:21             ` Matthew Wilcox
2020-05-29 12:46               ` Hannes Reinecke
2020-05-29 12:50                 ` Matthew Wilcox
2020-05-29 13:17                   ` Hannes Reinecke [this message]
2020-05-29 16:24                 ` Douglas Gilbert
2020-05-28 16:36 ` [PATCH 4/4] scsi: remove direct device lookup per host Hannes Reinecke
2020-05-29  4:21 ` [PATCHv3 0/4] scsi: use xarray ... scsi_alloc_target() Douglas Gilbert
  -- strict thread matches above, loose matches on Subject: below --
2020-05-28  8:42 [PATCHv2 0/4] Hannes Reinecke
2020-05-28  8:42 ` [PATCH 3/4] scsi: move target device list to xarray Hannes Reinecke
2020-05-27 14:13 [RFC PATCH 0/4] scsi: use xarray for devices and targets Hannes Reinecke
2020-05-27 14:13 ` [PATCH 3/4] scsi: move target device list to xarray Hannes Reinecke
2020-05-27 15:34   ` Johannes Thumshirn
2020-05-27 20:13   ` kbuild test robot
2020-05-30  2:47   ` kbuild test robot

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=7e9893bb-5445-7d71-205b-e22f256c8796@suse.de \
    --to=hare@suse.de \
    --cc=daniel.wagner@suse.com \
    --cc=dgilbert@interlog.com \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox