On 2016-05-30 03:09 PM, Christoph Hellwig wrote:
On Mon, May 30, 2016 at 12:02:45PM -0700, James Bottomley wrote:
This might fix the immediate warning, but won't it demand huge
contiguous memory chunks in high lun configurations and thus fail
randomly? Report luns is important to us because if that fails the
target won't attach.
What about vmalloc'ing enough space at configuration time, when you do
have process context, and simply reusing the already allocated buffer
in this routine? If you want to be clever, you could do a single
vmalloc for the biggest LUN size you have and reuse that buffer for
every report lun command with suitable locking ... we tend to fire off
report luns sequentially at start of day, so it's not like they have
huge performance or concurrency requirements.
There is no need for the allocation at all. Instead of the big
array and a single call to fill_from_dev_buffer we can simply
have a single scsi_lun structure on stack that gets reused for
every lun and individual calls to sg_copy_from_buffer for each
one instead of a single big one.
Christoph,
Interesting idea but a time waster due to:
s/sg_copy_from_buffer/sg_pcopy_from_buffer/
Otherwise the start of the sgl is overwritten by each subsequent
call. The "p" variant has a trailing 'off_t skip' argument and
currently there are no helper functions in scsi_cmnd.h for the
"pcopy" variants. Also handling the resid is fiddly, not helped by
initializing it to zero rather than scsi_bufflen().
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
