Roger Oberholtzer wrote:
On Wed, 2007-04-04 at 13:29 -0500, Jon Nelson wrote:
On Wed, 4 Apr 2007, Bill Anderson wrote:
I noticed that the default elevator applies to everything, including USB
memory sticks. I thought the block device driver would change the I/O
scheduler to something more appropriate for a memory stick, such as the noop
scheduler. I switched to the noop scheduler for just the memory stick, and
there was an improvement in performance. I haven't done a detailed statistical
analysis to verify my empirical impression.
I have a few questions:
1) Is there a reason for the block device driver not changing the I/O
scheduler to noop?
2) How do I modify HAL to change the I/O scheduler when it detects that a
hotplug for a memory stick?
I can't answer (1), and (2) is probably pretty easy.
However, let me offer an alternative:
set the *default* I/O scheduler (there /are/ several schedulers, you
know) to noop and then at boot time re-set your HDD (or whatever local
devices you want to change back) to "anticipatory" (or whatever you
use).
Perhaps this is related to an issue I am starting to look in to. I have
a system with a number of PCI I/O cards (firewire, video, SCSI, network)
as well as the good old serial ports (16550-based - not PCI). In some
system loads (not excessive) I see that the serial port driver starts to
report data overruns. I also see missing characters in GPS data read
over the serial port at this time. I am trying to see why these overruns
are happening. The serial port is operating at 38400. The 16550 can only
buffer 16 characters in hardware. So the device driver must service the
hardware within that time or data will be lost (handshake issues aside -
eventually some buffer can get full). Could it be that some device
driver has a higher priority and is blocking the serial port driver from
servicing the hardware? I am running whatever default priorities are in
SUSE 10.0. Am I looking in the right direction?.
The I/O Scheduler is part of the General Block I/O Layer. The Block I/O
Layer provides a generic interface to VFS to access block devices. Your
problem is with Character I/O, and is a totally different issue. The
kernel is, in a sense, a server that responds to interrupts and system
calls. Is there a chance that this a shared interrupt, and the card is
an ISA card that doesn't handler shared interrupts? The interrupt
handler runs in interrupt context, so is not subject to the process
scheduler. However, the bottom-half of the interrupt driver may run in
process context, which would make it subject to the process scheduler. I
am trying to think of the steps to trace this symptom to the actual
problem. I need to think about this one.
Bill Anderson
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
