* Re: [Bug 15565] New: SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
@ 2010-03-18 2:19 ` Douglas Gilbert
2010-03-18 9:56 ` Boaz Harrosh
2010-03-18 2:20 ` [Bug 15565] " bugzilla-daemon
` (8 subsequent siblings)
9 siblings, 1 reply; 19+ messages in thread
From: Douglas Gilbert @ 2010-03-18 2:19 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: linux-scsi
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>
> Summary: SCSI Generic queueing completes commands in reverse
> order
> Product: IO/Storage
> Version: 2.5
> Kernel Version: 2.6.18-2.6.32
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: SCSI
> AssignedTo: linux-scsi@vger.kernel.org
> ReportedBy: mh-linux-kernel@loup.net
> Regression: No
>
>
> I've noticed after queueing the first command, subsequent commands
> appear to be executed and complete in reverse order. The SCSI Generic
> HOWTO says "By default, read() will return the oldest completed
> request that is queued up."
>
> This could also be a performance defect if it's what's really
> happening since it isn't desirable behavior if, for example, ios are
> typically ordered by lba and issued one at a time by kernel to a non
> queueing block device.
>
> This reverse order behavior is trivial to reproduce; just queue 16
> concurrent INQUIRY commands. The following are typical results I get
> from initially queueing 16 READ_10 commands.
>
> Completion Command # hdr.driver_duration (us)
> Order
> 1 22 14979
> 2 20 14981
> 3 19 14982
> 4 17 14984
> 5 16 14985
> 6 15 14986
> 7 14 14988
> 8 12 14990
> 9 11 14991
> 10 10 14992
>
I have been told that is a feature :-)
The SCSI mid level processes commands from
pass-throughs (e.g. sg and bsg) in LIFO order.
For certain types of error processing it makes
sense. For READs and WRITEs it makes no sense.
Doug Gilbert
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bug 15565] New: SCSI Generic queueing completes commands in reverse order
2010-03-18 2:19 ` Douglas Gilbert
@ 2010-03-18 9:56 ` Boaz Harrosh
0 siblings, 0 replies; 19+ messages in thread
From: Boaz Harrosh @ 2010-03-18 9:56 UTC (permalink / raw)
To: dgilbert; +Cc: bugzilla-daemon, linux-scsi
On 03/18/2010 04:19 AM, Douglas Gilbert wrote:
> bugzilla-daemon@bugzilla.kernel.org wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>>
>> Summary: SCSI Generic queueing completes commands in reverse
>> order
>> Product: IO/Storage
>> Version: 2.5
>> Kernel Version: 2.6.18-2.6.32
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: SCSI
>> AssignedTo: linux-scsi@vger.kernel.org
>> ReportedBy: mh-linux-kernel@loup.net
>> Regression: No
>>
>>
>> I've noticed after queueing the first command, subsequent commands
>> appear to be executed and complete in reverse order. The SCSI Generic
>> HOWTO says "By default, read() will return the oldest completed
>> request that is queued up."
>>
>> This could also be a performance defect if it's what's really
>> happening since it isn't desirable behavior if, for example, ios are
>> typically ordered by lba and issued one at a time by kernel to a non
>> queueing block device.
>>
>> This reverse order behavior is trivial to reproduce; just queue 16
>> concurrent INQUIRY commands. The following are typical results I get
>> from initially queueing 16 READ_10 commands.
>>
>> Completion Command # hdr.driver_duration (us)
>> Order
>> 1 22 14979
>> 2 20 14981
>> 3 19 14982
>> 4 17 14984
>> 5 16 14985
>> 6 15 14986
>> 7 14 14988
>> 8 12 14990
>> 9 11 14991
>> 10 10 14992
>>
>
> I have been told that is a feature :-)
>
> The SCSI mid level processes commands from
> pass-throughs (e.g. sg and bsg) in LIFO order.
> For certain types of error processing it makes
> sense. For READs and WRITEs it makes no sense.
>
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.
> Doug Gilbert
>
It could be added to sg as well if needed
Boaz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
2010-03-18 2:19 ` Douglas Gilbert
@ 2010-03-18 2:20 ` bugzilla-daemon
2010-03-18 8:23 ` bugzilla-daemon
` (7 subsequent siblings)
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-18 2:20 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #1 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2010-03-18 02:20:02 ---
Reply-To: dgilbert@interlog.com
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>
> Summary: SCSI Generic queueing completes commands in reverse
> order
> Product: IO/Storage
> Version: 2.5
> Kernel Version: 2.6.18-2.6.32
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: SCSI
> AssignedTo: linux-scsi@vger.kernel.org
> ReportedBy: mh-linux-kernel@loup.net
> Regression: No
>
>
> I've noticed after queueing the first command, subsequent commands
> appear to be executed and complete in reverse order. The SCSI Generic
> HOWTO says "By default, read() will return the oldest completed
> request that is queued up."
>
> This could also be a performance defect if it's what's really
> happening since it isn't desirable behavior if, for example, ios are
> typically ordered by lba and issued one at a time by kernel to a non
> queueing block device.
>
> This reverse order behavior is trivial to reproduce; just queue 16
> concurrent INQUIRY commands. The following are typical results I get
> from initially queueing 16 READ_10 commands.
>
> Completion Command # hdr.driver_duration (us)
> Order
> 1 22 14979
> 2 20 14981
> 3 19 14982
> 4 17 14984
> 5 16 14985
> 6 15 14986
> 7 14 14988
> 8 12 14990
> 9 11 14991
> 10 10 14992
>
I have been told that is a feature :-)
The SCSI mid level processes commands from
pass-throughs (e.g. sg and bsg) in LIFO order.
For certain types of error processing it makes
sense. For READs and WRITEs it makes no sense.
Doug Gilbert
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
2010-03-18 2:19 ` Douglas Gilbert
2010-03-18 2:20 ` [Bug 15565] " bugzilla-daemon
@ 2010-03-18 8:23 ` bugzilla-daemon
2010-03-18 10:33 ` bugzilla-daemon
` (6 subsequent siblings)
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-18 8:23 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #2 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-18 08:23:55 ---
Hey Doug,
> bugzilla-daemon@bugzilla.kernel.org wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=15565
> >
> > Summary: SCSI Generic queueing completes commands in reverse
> > order
>
> I have been told that is a feature :-)
>
> The SCSI mid level processes commands from
> pass-throughs (e.g. sg and bsg) in LIFO order.
> For certain types of error processing it makes
> sense. For READs and WRITEs it makes no sense.
Thanks for the confirmation; it in fact it makes anti sense to a
spinning disk drive! Without drive command queueing it's causing the
maximum rotational delay for reads or writes with caching disabled,
maximizing latency and minimizing throughput to a given track. Ouch.
I assume libaio does not exhibit this behavior, or is everything
running through the scsi mid level and just depending on adjacent io
aggregation to help reduce rotational latency? I'm guessing I'll have
to use libaio to get good disk performance in the near future and save
sg for controlling caching, etc.
Bummer since SCSI gives much better control, like priority ios to a
journal, which NCQ can actually grant and SCSI-ATA translation should
support or SCSI drive can honor closer to the media. Or FUA & DPO, or
command ordering to pipeline a barrier.
- Mike
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (2 preceding siblings ...)
2010-03-18 8:23 ` bugzilla-daemon
@ 2010-03-18 10:33 ` bugzilla-daemon
2010-03-18 17:21 ` bugzilla-daemon
` (5 subsequent siblings)
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-18 10:33 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #3 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2010-03-18 10:32:31 ---
Reply-To: bharrosh@panasas.com
On 03/18/2010 04:19 AM, Douglas Gilbert wrote:
> bugzilla-daemon@bugzilla.kernel.org wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>>
>> Summary: SCSI Generic queueing completes commands in reverse
>> order
>> Product: IO/Storage
>> Version: 2.5
>> Kernel Version: 2.6.18-2.6.32
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: SCSI
>> AssignedTo: linux-scsi@vger.kernel.org
>> ReportedBy: mh-linux-kernel@loup.net
>> Regression: No
>>
>>
>> I've noticed after queueing the first command, subsequent commands
>> appear to be executed and complete in reverse order. The SCSI Generic
>> HOWTO says "By default, read() will return the oldest completed
>> request that is queued up."
>>
>> This could also be a performance defect if it's what's really
>> happening since it isn't desirable behavior if, for example, ios are
>> typically ordered by lba and issued one at a time by kernel to a non
>> queueing block device.
>>
>> This reverse order behavior is trivial to reproduce; just queue 16
>> concurrent INQUIRY commands. The following are typical results I get
>> from initially queueing 16 READ_10 commands.
>>
>> Completion Command # hdr.driver_duration (us)
>> Order
>> 1 22 14979
>> 2 20 14981
>> 3 19 14982
>> 4 17 14984
>> 5 16 14985
>> 6 15 14986
>> 7 14 14988
>> 8 12 14990
>> 9 11 14991
>> 10 10 14992
>>
>
> I have been told that is a feature :-)
>
> The SCSI mid level processes commands from
> pass-throughs (e.g. sg and bsg) in LIFO order.
> For certain types of error processing it makes
> sense. For READs and WRITEs it makes no sense.
>
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.
> Doug Gilbert
>
It could be added to sg as well if needed
Boaz
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (3 preceding siblings ...)
2010-03-18 10:33 ` bugzilla-daemon
@ 2010-03-18 17:21 ` bugzilla-daemon
2010-03-18 18:02 ` Boaz Harrosh
2010-03-18 18:03 ` bugzilla-daemon
` (4 subsequent siblings)
9 siblings, 1 reply; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-18 17:21 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #4 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-18 17:21:05 ---
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?
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.
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.
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.
- Mike
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-18 17:21 ` bugzilla-daemon
@ 2010-03-18 18:02 ` Boaz Harrosh
2010-03-18 19:30 ` Douglas Gilbert
0 siblings, 1 reply; 19+ messages in thread
From: Boaz Harrosh @ 2010-03-18 18:02 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: linux-scsi
Please switch to mail ?
On 03/18/2010 07:21 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>
>
>
>
>
> --- Comment #4 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-18 17:21:05 ---
> 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
...
> - Mike
>
Boaz
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-18 18:02 ` Boaz Harrosh
@ 2010-03-18 19:30 ` Douglas Gilbert
2010-03-19 19:41 ` Vladislav Bolkhovitin
0 siblings, 1 reply; 19+ messages in thread
From: Douglas Gilbert @ 2010-03-18 19:30 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: bugzilla-daemon, linux-scsi
Boaz Harrosh wrote:
> Please switch to mail ?
>
> On 03/18/2010 07:21 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>>
>>
>>
>>
>>
>> --- Comment #4 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-18 17:21:05 ---
>> 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.
Doug Gilbert
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-18 19:30 ` Douglas Gilbert
@ 2010-03-19 19:41 ` Vladislav Bolkhovitin
2010-03-19 20:57 ` Michael Reed
0 siblings, 1 reply; 19+ messages in thread
From: Vladislav Bolkhovitin @ 2010-03-19 19:41 UTC (permalink / raw)
To: dgilbert; +Cc: Boaz Harrosh, bugzilla-daemon, linux-scsi
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-19 19:41 ` Vladislav Bolkhovitin
@ 2010-03-19 20:57 ` Michael Reed
2010-03-21 11:45 ` Boaz Harrosh
0 siblings, 1 reply; 19+ messages in thread
From: Michael Reed @ 2010-03-19 20:57 UTC (permalink / raw)
To: Vladislav Bolkhovitin; +Cc: dgilbert, Boaz Harrosh, bugzilla-daemon, linux-scsi
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.
Mike
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-19 20:57 ` Michael Reed
@ 2010-03-21 11:45 ` Boaz Harrosh
0 siblings, 0 replies; 19+ messages in thread
From: Boaz Harrosh @ 2010-03-21 11:45 UTC (permalink / raw)
To: Michael Reed; +Cc: Vladislav Bolkhovitin, dgilbert, bugzilla-daemon, linux-scsi
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (4 preceding siblings ...)
2010-03-18 17:21 ` bugzilla-daemon
@ 2010-03-18 18:03 ` bugzilla-daemon
2010-03-18 19:31 ` bugzilla-daemon
` (3 subsequent siblings)
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-18 18:03 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #5 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2010-03-18 18:03:17 ---
Reply-To: bharrosh@panasas.com
Please switch to mail ?
On 03/18/2010 07:21 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>
>
>
>
>
> --- Comment #4 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-18 17:21:05 ---
> 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
...
> - Mike
>
Boaz
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (5 preceding siblings ...)
2010-03-18 18:03 ` bugzilla-daemon
@ 2010-03-18 19:31 ` bugzilla-daemon
2010-03-19 20:30 ` bugzilla-daemon
` (2 subsequent siblings)
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-18 19:31 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2010-03-18 19:31:04 ---
Reply-To: dgilbert@interlog.com
Boaz Harrosh wrote:
> Please switch to mail ?
>
> On 03/18/2010 07:21 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=15565
>>
>>
>>
>>
>>
>> --- Comment #4 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-18 17:21:05 ---
>> 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.
Doug Gilbert
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (6 preceding siblings ...)
2010-03-18 19:31 ` bugzilla-daemon
@ 2010-03-19 20:30 ` bugzilla-daemon
2010-03-19 21:36 ` bugzilla-daemon
2010-03-20 3:28 ` bugzilla-daemon
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-19 20:30 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #7 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2010-03-19 20:30:49 ---
Reply-To: vst@vlnb.net
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
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (7 preceding siblings ...)
2010-03-19 20:30 ` bugzilla-daemon
@ 2010-03-19 21:36 ` bugzilla-daemon
2010-03-20 3:28 ` bugzilla-daemon
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-19 21:36 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #8 from Michael Reed <mdr@sgi.com> 2010-03-19 21:36:40 ---
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.
Mike
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug 15565] SCSI Generic queueing completes commands in reverse order
2010-03-17 22:33 [Bug 15565] New: SCSI Generic queueing completes commands in reverse order bugzilla-daemon
` (8 preceding siblings ...)
2010-03-19 21:36 ` bugzilla-daemon
@ 2010-03-20 3:28 ` bugzilla-daemon
9 siblings, 0 replies; 19+ messages in thread
From: bugzilla-daemon @ 2010-03-20 3:28 UTC (permalink / raw)
To: linux-scsi
http://bugzilla.kernel.org/show_bug.cgi?id=15565
--- Comment #9 from Mike Hayward <mh-linux-kernel@loup.net> 2010-03-20 03:28:33 ---
> 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.
I obtained more evidence today that not only is it reversing arbitrary
subsets of commands nonsensically, but it is a starvation queue as
well (no reasonable deadline to drain the LIFO).
This time I ran sg queued io on a wimpier arm machine via usb to a
real hard drive with only one drive on the bus to eliminate the
possibility that the usb bus could be unfair between devices. The
slower cpu also helped quantify kernel cpu burn and latency issues.
Blocking writes to a drive with the write cache on ran at 20MB/s, only
10MB/s via sg with the exact same io load. Not sure why it's so much
lower bandwidth on an arm kernel but it seems it must have additional
latency, mem copy, etc. going on.
Regardless, it took over 33 seconds to complete a write to a drive
which was bypassed by hundreds and hundreds of subsequent writes,
starving until finally there was enough of a lull that the LIFO
'queue' must have drained.
A starving task queue is definitely not a SCSI task queue. I must
conclude that there isn't even a need for a "works correctly" flag to
be added to support forward compatibility if someone fixes this.
1. It is the SCSI target which should manage task ordering according
to command attributes, not the initiator.
2. If an existing app can cope with starvation and arbitrary
reordering of commands, then simply fixing the queue to send
out commands in the order submitted shouldn't break it. In all
likelihood it could speed up a simple target if command order
matters at all. Am I missing something here?
- Mike
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread