Mailinglist Archive: opensuse (3175 mails)
|< Previous||Next >|
Re: [opensuse] Elevator Question
- From: Bill Anderson <bill@xxxxxxxxxxxxxxxxx>
- Date: Wed, 11 Apr 2007 11:31:12 -0600
- Message-id: <461D1B60.60102@xxxxxxxxxxxxxxxxx>
Roger Oberholtzer wrote:
On Wed, 2007-04-04 at 13:29 -0500, Jon Nelson wrote: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.
On Wed, 4 Apr 2007, Bill Anderson wrote:
I noticed that the default elevator applies to everything, including USBI can't answer (1), and (2) is probably pretty easy.
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?
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?.
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
|< Previous||Next >|