From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 15567] New: SCSI Generic queueing appears unfair between processes
Date: Wed, 17 Mar 2010 22:54:57 GMT [thread overview]
Message-ID: <bug-15567-11613@http.bugzilla.kernel.org/> (raw)
http://bugzilla.kernel.org/show_bug.cgi?id=15567
Summary: SCSI Generic queueing appears unfair between processes
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
My timing indicates there appears to be no fair queueing mechanism for
scsi commands issued from multiple processes to separate devices over
a shared bus (e.g. SCSI or USB). For example, an io can easily be
starved in queue for more than half a minute with just four processes
issuing 16 slow ios to usb flash devices at a time. If I hold back
ios in my application and reduce the number of ios queued in the
kernel at a time to 2 per process it decreases average and maximum end
to end latency to more tolerable levels.
Much like memory, cpu or network hogging, unfair storage command
queueing between processes would be considered by most people to be a
performance related defect. Shared use, particularly of a congested
bus, calls for time or bandwidth slicing to prevent starvation.
The SCSI Generic HOWTO doesn't go into it, but is this the current
kernel design? If so, perhaps libaio would be a more viable solution
to concurrent io?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
reply other threads:[~2010-03-17 22:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bug-15567-11613@http.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).