Re: [Bug 15565] SCSI Generic queueing completes commands in reverse order

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/19/2010 10:57 PM, Michael Reed wrote:
> 
> 
> Vladislav Bolkhovitin wrote:
>> Douglas Gilbert, on 03/18/2010 10:30 PM wrote:
>>>>> Hi Boaz,
>>>>>
>>>>>  > I have fixed that for bsg long ago. There is a flag
>>>>>  > that you put:
>>>>>  >     sg.flags = BSG_FLAG_Q_AT_TAIL;
>>>>>  > Which will do the by order, queue at tail. Zero was kept compatible
>>>>>  > to sg meaning "queue at head" i.e. jump the line.
>>>>>  > 
>>>>>  > It could be added to sg as well if needed
>>>>>
>>>>> I think that would be a huge improvement for disk drives.
>>>>>
>>>>> Isn't BSG driven with a blocking ioctl?  Maybe I'm using old docs, but
>>>>> from the HOWTO's I've read, I was under the impression it would issue
>>>>> one SCSI command at a time and block until it completed.  Queueing
>>>>> would effectively only be possible then with multiple threads, right?
>>>>>
>>>> There is a way to do write with multiple ios at once and then
>>>> do reads to get return status. (I have untested code that does
>>>> that but never needed it so badly as to finish it. But I know
>>>> of other people that did it)
>>>>
>>>> bsg does not have all these mmap/shared buffers options like
>>>> sg does, though. Hell not even AIOs.
>>>>
>>>>> Since sg allows multiple (only 16 right now) ios to be queued
>>>>> nonblocking to a block device from a single threaded process,
>>>>> an SG_FLAG_Q_AT_TAIL flag would seem particularly relevant.
>>>>>
>>>> Yes. Currently the queue of 16 does nothing because in effect the
>>>> Kernel will completely drain the Q on each "Q_AT_HEAD". So the Q
>>>> does nothing for IO with current sg.
>>>>
>>>>> Nonblocking behavior is the primary reason why I am using sg... it
>>>>> seems really inefficient and complex to use dozens of threads and ipc
>>>>> just to try to submit a queue of ios to the kernel and hence a device.
>>>>>
>>>> There are surely other ways to do AIO, no?
>>>> (The A in AIO stands for Asynchronous)
>>>>
>>>>> If bsg actually allowed tasks to be queued nonblocking like sg, I'd
>>>>> switch in a heart beat since having two filesystem names for the same
>>>>> device introduces locking problems, name translation complexity, and
>>>>> confusion in general for administrators.
>>>>>
>>>> Well bsg has it's own naming translation. You do not use /dev/sdX1. You
>>>> need to open the bsg char-device corresponding the particular scsi-device
>>> What might be useful is to tell the sd driver not to hook
>>> a particular logical unit with peripheral device type 0
>>> (i.e. a disk). Perhaps this could be done via the LU
>>> UUID. That way udev (?) would be less tempted to send
>>> crap commands to the device at random times.
>>>
>>> After that you only have to worry about the device node
>>> duality between bsg and sg :-)
>>> They are pretty well behaved, only sending commands when
>>> they are asked to.
>>>
>>>
>>> Adding a SG_FLAG_Q_AT_TAIL flag to sg seems like a
>>> good idea.
>>
>> Great so see the problem confirmed and it's going to move! I and other 
>> people have been asking this for 3 (or 4?) years and have had a silence 
>> in reply. It hasn't even been confirmed, so I'd prepare a patch.
>>
>> Eventually, this should be fixed.
>>
>> Vlad
> 
> 
> We're looking at supporting a non-disk scsi device which can effectively
> process a queue depth of nine in parallel.  Having our application access
> the hardware via the "sg" device is our first choice on how to proceed.
> 
> My reading of this thread indicates that the 9 parallel commands we'll
> issue will be effectively single threaded by the kernel due to their
> being queued at the head of the queue.
> 
> I'd like to encourage the implementation of SG_FLAG_Q_AT_TAIL for
> sg devices.
> 

Why not use bsg, then?

> Mike

Boaz
--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux