Kolivas Pushes New Kernel Responsiveness Patches

[RealNC]

I am sure there should be a way to set disk I/O priority for individual processes in Linux.

There is, and it helps a bit, but not much. The tool to set I/O priority is called "ionice."

[suokko]

Yep. Windows 7 here does indexing too. Never notice it. Hell, I can start defrag which is hammering the disk without tomorrow and I can still play Mass Effect as if nothing is happening. The only term suitable to describe Linux kernel I/O performance is "crapfest."

lol.

Problem here is more complex. And in my option mostly because kernel devs don't understand desktop. Whole disk io is designed in linux to have maximum thoughput. Maximum thoughput often means filling hardware buffers full which adds latencies when something should respond very fast to important operation.
For comparison to Windows that limits aggressively disk i/o performance so it doesn't affect desktop interactivity. (Have you ever notice how long file copy operations or software installation takes time in windows?)

I don't know if there is any options to change i/o system towards low latency operation. But maybe you could hack something if there isn't any yet

Also you don't want to start swapping when disk i/o queue is full. It is just going to painful.

I agree that many kernel devs are clearly looking wrong benchmarks. Desktop is not about maximum disk or network performance. It is all about minimum latency for important operations. This often completely different in servers where hw has to be pushed to the limit and minor extra latency isn't going to affect much. (minor server latency is huge desktop latency)

[karl]

Who's talking about Firefox? ...

The parent poster was.
(actually he didn't mentioned Firefox, he just said "browser" but I assume that he was referring to Firefox).

[karl]

There is, and it helps a bit, but not much. The tool to set I/O priority is called "ionice."

I my case ionice doesn't help.
Example: I start to un-zip a big archive (~1GB). I set this process to idle ionice (I also set the nice to 19). Then I open firefox. On my system it takes ages.
In my naivete I would had expected to see normal firefox start-up times (because the un-zip-ing should only happen on idle, when there is no disk i/o going on but somehow this is not the case - on my system).

[kraftman]

You should try the latest kernel. I can't remember which kernel has it (2.6.32 or 2.6.33) but there's a change in there that should significantly improve IO read latencies under heavy write loads.

Yes, it's probably 2.6.31 (Ubuntu kernel).

[Hephasteus]

I think most of the people who work on the kernel work in environments where there's no such thing as uncoprocessed disk actviity. So they really don't know what desktop users are talking about as they have huge risc chips that do all that for them.

[karl]

I think most of the people who work on the kernel work in environments where there's no such thing as uncoprocessed disk actviity. So they really don't know what desktop users are talking about as they have huge risc chips that do all that for them.

In that case I think all we can do is buy an Intel SSD (the only problem is they are so expensive).

[Ex-Cyber]

I think most of the people who work on the kernel work in environments where there's no such thing as uncoprocessed disk actviity. So they really don't know what desktop users are talking about as they have huge risc chips that do all that for them.

I'm pretty sure that at least a few kernel devs use laptops...

[energyman]

I am particularly suspicious of the 10000Hz patch. A higher tick rate means more overhead. On the other hand, the overhead may still be tolerable on a fast system.

Really, the thing that annoys me the most is system unresponsiveness in the face of high I/O. I can understand that reading a file can take a while if there is a lot of other disk I/O going on, but switching tabs on my browser should not be affected.

exactly! All that 'responsiveness' crap means nothing as long as copy'ing a file makes the mouse jerky!

[arjan_intel]

Until a few kernels ago, HZ was very user visible, because the select() and poll() system calls rounded internally to HZ values. That was the one place where HZ was really visible, esp HZ=100 and to some degree, HZ=250.
However, current kernels don't have this rounding anymore for select() and poll()... so I'm curious where Con thinks that the HZ value actually makes a difference still for userspace applications.

For all those who complain about disk IO issues, while I have no doubt your complaints are real, those are rather very independent from the process scheduler; that's the disk scheduler. BFS is a process scheduler change, not a disk scheduler...

2.6.33 has some very interesting changes to the kernel scheduler, that cut down latencies quite a bit, especially on multicore/hyperthreaded cpus (there was a behavior issue fixed where idle cpus weren't used aggressively enough).

For those who still see latencies, it would be interesting to capture a timechart of the hickup/etc to see what is going on in the system; the timechart can show you what delays are due to scheduler, and what delays are disk, and what delays are just communication to other processes etc etc.