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).

-- Carpe diem - Seize the day. Carp in denim - There's a fish in my pants!

Jon Nelson

Setting elevator=<somevalue> as boot command changes the default scheduler. It would really slow down the disk until it reached the boot.local script. Under Suse 10.2 and FC6, the kernel default scheduler is CFQ. I still want CFQ for the USB DVD drive, or a thumb drive. Thus, I am looking for a way for to configure HAL to change the elevator from cfq to noop upon detection of the memory stick. Bill Anderson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Seth Arnold wrote:

On Wed, Apr 04, 2007 at 03:29:34PM -0600, Bill Anderson wrote:

...

boot.local script. Under Suse 10.2 and FC6, the kernel default scheduler is CFQ. I still want CFQ for the USB DVD drive, or a thumb drive. Thus, I am looking for a way for to configure HAL to change the elevator from cfq to noop upon detection of the memory stick.

No idea about the HAL end of things, but if you can figure out how to get it to issue arbitrary commands when devices are attached, you could echo the scheduler you want to /sys/block/whatever/queue/scheduler

I forgot to mention that I already used that method to change the scheduler for testing. It works fine, but I was looking for an automated method. hald already responds to the hotplug with a mount. It knows the device information, so if I could just make it smarter. Bill Anderson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Thursday 2007-04-05 at 11:39 -0600, Bill Anderson wrote:

...

I forgot to mention that I already used that method to change the scheduler for testing.

I'm curious to learn a bit about that method. Do you have a link to some info, perhaps?

- -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76

iD8DBQFGFrGutTMYHG2NR9URAmONAKCNF1pJ1MYLc8bh5UVAIsJ3yTdYogCePuBj SNJkmRnrWyuIYg79PzUm3Bs= =9BOL -----END PGP SIGNATURE-----

If you have the kernel source installed, you will find several documents relating to I/O schedulers in the Documentation/block directory. It was through these documents that I discovered the ionice command, which only applies if you are using CFQ as an I/O scheduler. Alas, I am still looking for more information on CFQ tuning. Bill Anderson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 06 April 2007 17:19, Carlos E. R. wrote: ...

Yes, I use ionice. But it is not very usefull, only root can use it. For instance, I have to copy large files, and I'm not really interested in doing it fast, rather to be able to keep working on something else at the same time. So, I fire the copy, find out the pid, then as root I re-io-nice it. That should not require root priviledges. ....

The top, R key for renice user process should do the same from user console. -- Regards, Rajko. http://en.opensuse.org/Portal -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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?. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, 2007-04-10 at 17:08 +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Tuesday 2007-04-10 at 13:12 +0200, Roger Oberholtzer wrote:

...

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.

Surprising... :-O

I get the point. But I do not think I have reached any resource limits when this happens. I know that is hard to judge. And I could be very wrong.

...

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).

Hum.

This should not happen. The hardware should be able to signal the other side that it is not ready to receive data - that's what hardware handshake is for. Even an old 8086 was able to service the serial port at maximum speed, and if it couldn't, the other end would pause. The same should happen now with modern hardware.

I would look at the hardware handshake lines first.

It is being investigated. We are using cables made by Trimble that they feel we should really use. I am having the GPS receivers checked for any unexpected settings. The serial port really has limited settings. But that does not mean the users have not found something to cause problems.

...

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?.

Maybe.

Interrupts are interrupts, should be attended regardless of conditions, although maybe later. If there is an unwanted delay, and there can be unless you have on a real time system (warrantied maximum response time), the system (hardware) should be able to inform the sending side to slow down and wait.

If hardware handshaking is impossible, revert to software handshake (much slower, chars have to be sent back)

But the software handshake must require that the driver is getting called in time, no? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Tuesday 2007-04-10 at 17:27 +0200, Roger Oberholtzer wrote:

...

...

...

report data overruns. I also see missing characters in GPS data read over the serial port at this time.

Surprising... :-O

I get the point. But I do not think I have reached any resource limits when this happens. I know that is hard to judge. And I could be very wrong.

Yep. But it is indeed surprising that this could happen with current hardware. I wasn't even aware that it could happen. You see, if a plain 8086 could cope (barely) at 115000, a pentium should not even cough.

It might be worth a bugzilla report...

Another idea. There are some settings in the kernel about how fast is the task switcher clock and how interruptible are some tasks, and real time settings. Playing with that could help. I have found that some times, when a task is busy (mozilla!) the response to the keyboard is sluggish, might be related to your problem. I have been playing a little with those settings, but I'm not learned enough on linux kernels to recommend anything conclusive.

...

...

If hardware handshaking is impossible, revert to software handshake (much slower, chars have to be sent back)

But the software handshake must require that the driver is getting called in time, no?

Exactly; in your case it wouldn't be much use, or none at all. Mmmm...

- -- Cheers, Carlos E. R.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76

iD8DBQFGHYgxtTMYHG2NR9URAkOVAJ9ad/giFiYb4FBhi6J1ExI8bV4iogCeOECk OF1MEQgQzc5PIziaXY0Ly94= =nfXn -----END PGP SIGNATURE-----

Changing the HZ to 1000 would only impact on tasks running in the process context. The top-half of the interrupt handler runs in interrupt context. During the initial processing of an interrupt, the handler suspends other interrupts on the same IRQ. Remember this is character I/O, so there is going to be an interrupt for each character. The buffering of the data for a user application occurs in the bottom half of the interrupt handler. I forgot to ask if the GPS application reads the raw serial port, or uses a kernel module for gathering the data. Bill Anderson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 08 April 2007, David Brodbeck wrote:

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.

While we're on the subject, I've also noticed that memory sticks are no longer mounted with synchronous writes in 10.2. I very nearly found this out the hard way, by losing data. I now make sure I issue a 'sync' command before unplugging my memory stick.

I always get a desktop icon in KDE which has a Safe Remove option. -- _____________________________________ John Andersen

...

I always get a desktop icon in KDE which has a Safe Remove option. Hmm, I'll have to look for that. I hadn't noticed it.

GNOME offers the same thing, right click -> eject You can't just yank removable media in any OS. -- -- Adam Tauno Williams Network & Systems Administrator Consultant - http://www.whitemiceconsulting.com Developer - http://www.opengroupware.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 9 Apr 2007, Greg Freemyer wrote:

On 4/9/07, Adam Tauno Williams wrote:

...

...

...

I always get a desktop icon in KDE which has a Safe Remove option. Hmm, I'll have to look for that. I hadn't noticed it.

GNOME offers the same thing, right click -> eject

You can't just yank removable media in any OS.

In SUSE 10.0 and prior you could by default. ie. It was mounted in sync mode. (no caching)

But user complaints about how slow USB drives were caused Novell to design a new FAT32 mode that is a comprise between "sync" mode and normal cached mode.

From the 2.6.19 readme: === FAT: Add "-o flush" mount option for fat for removable media devices (USB flash-based memory devices, MP3 players). Mounting with -o flush tells FAT to write things to disk as quickly as possible. It is like -o sync, but much faster (and not as safe). Think of it like a fast "async" mount (commit) ===

Hey, that's pretty cool! Thanks for finding that. -- Carpe diem - Seize the day. Carp in denim - There's a fish in my pants! Jon Nelson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David Brodbeck wrote:

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.

While we're on the subject, I've also noticed that memory sticks are no longer mounted with synchronous writes in 10.2. I very nearly found this out the hard way, by losing data. I now make sure I issue a 'sync' command before unplugging my memory stick.

I also noticed this behavior. At one point the default I/O scheduler was anticipatory, the current default scheduler is CFQ. I suspect this behavior is a result of one of the CFQ parameters, as it keeps thinking the memory stick is a disk and attempts to minimize seeks. The resulting delay caused by the elevator policy could result in a delay to write operations, especially if you were doing a series of reads. With the noop scheduler, this behavior disappears as there is attempt to optimize seeks. I have to go through the noop code, but I don't think it has a bias towards reads over writes. With other I/O schedulers, reads have operations have precedence of writes, as long as they don't starve writes. The documentation on CFQ is very sparse, and a bit dated. Does anyone know where I can find current CFQ documentation. I am especially interested in documents related to tuning the current version of CFQ. Bill Anderson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org