Linked by Thom Holwerda on Thu 25th Apr 2013 14:56 UTC
Ubuntu, Kubuntu, Xubuntu Ubuntu 13.04 has been released, with the Linux 3.8.8 kernel, a faster and less resource hungry Unity desktop, LibreOffice 4.0, and much more. Ubuntu users will know where to get it, and you're looking for a new installation, have fun. Also fun: UbuntuKylin.
Thread beginning with comment 559734
To read all comments associated with this story, please click here.
"It's the disk I/O, stupid."
by Gullible Jones on Thu 25th Apr 2013 20:26 UTC
Gullible Jones
Member since:
2006-05-23

BTW, a note on performance. Pretty much every major serious performance problem I've run into on Linux has involved disk I/O. Whenever you have
- Thrashing due to low memory conditions
- Large programs being read into memory
- Big disk writes
things slow way down. Especially with the latter.

Current "solutions" on Linux seem to revolve around delaying writes for as long as possible. IMO this is doubly stupid, because
a) Eventually the data must be written, and when it is you want the write to be of manageable size.
b) If your desktop freezes, your kernel panics, or your power fails, you do NOT want saved data to be stuck in RAM.

However, I'll readily admit I don't actually have a clue what would constitute a sane, broadly applicable solution; or if such a thing could even exist. If anyone has ideas on that, I'm all ears.

Edited 2013-04-25 20:27 UTC

Reply Score: 2

RE: "It's the disk I/O, stupid."
by Kochise on Thu 25th Apr 2013 21:02 in reply to ""It's the disk I/O, stupid.""
Kochise Member since:
2006-03-03

Same for Windows : having 8 GB of RAM I disabled the virtual memory : 1- faster application starting, 2- snapier computer, 3- saved 12 GB on my hard disk.

Kochise

Reply Parent Score: 2

lucas_maximus Member since:
2009-08-18

LOL, you know that a modern OS expects virtual memory.

These hacks from Windows 2000 day that people used to do are laughable.

Reply Parent Score: 3

RE: "It's the disk I/O, stupid."
by Alfman on Fri 26th Apr 2013 01:42 in reply to ""It's the disk I/O, stupid.""
Alfman Member since:
2011-01-28

Gullible Jones,

"Whenever you have
- Thrashing due to low memory conditions
- Large programs being read into memory
- Big disk writes
things slow way down. Especially with the latter."

Actually it depends greatly on whether the reads/writes are sequential or random. Just now I conducted a short test:

I timed the time it takes to read 2048 (10MiB) sectors individually using a sequential access pattern at random starting disk positions. On my system it took 0.03s or 333MiB/s.

I read another 2048 sectors, but this time with a random access pattern. This took 27.71s or 0.36MiB/s.

As you can see, the slowness is almost entirely caused by disk seeking, raw speed is plenty fast and this is on equipment that's 5 years old already. Oh, I would have tested writes as well but I don't have a sacrificial disk to write to in this system ;)


"Current 'solutions' on Linux seem to revolve around delaying writes for as long as possible. IMO this is doubly stupid, because a) Eventually the data must be written, and when it is you want the write to be of manageable size."

You can disable delayed writes, but think about what that would do in terms of total seeks. I could write each sector immediately to disk as soon as I get it (and cause lots of seeks), or I could try to bundle as many sectors as I can together, and then write them all at once.

"b) If your desktop freezes, your kernel panics, or your power fails, you do NOT want saved data to be stuck in RAM."

Fair point.

"However, I'll readily admit I don't actually have a clue what would constitute a sane, broadly applicable solution; or if such a thing could even exist. If anyone has ideas on that, I'm all ears."

There are some answers to the problem. Servers have battery backup disk cache, but these aren't found on consumer equipment. It seems like it should be feasible on a laptop, since it already has the battery ;) Also, solid state disks don't have as much seek latency as the spinny ones. As for software FS solutions, we'd have to research ways to consolidate reads. If we are reading 2000 files at bootup, that's almost 30s wasted to seeks in my little experiment. The FS should really be able to keep them ordered sequentially, that way the OS could read all 100MB it needs within 2s.

Reply Parent Score: 4

RE: "It's the disk I/O, stupid."
by Savior on Fri 26th Apr 2013 06:56 in reply to ""It's the disk I/O, stupid.""
Savior Member since:
2006-09-02

BTW, a note on performance. Pretty much every major serious performance problem I've run into on Linux has involved disk I/O.


So true.

However, I'll readily admit I don't actually have a clue what would constitute a sane, broadly applicable solution; or if such a thing could even exist. If anyone has ideas on that, I'm all ears.


I don't know if it counts as a solution, but ionice'ing every big "offender", while giving priority to the UI could help. Unfortunately, nothing like this is being done -- whenever e.g. the apt cache kicks in in the background, everything just becomes unresponsive (it took me a while to find out why I experience sporadic lags). Or, we'd need a saner scheduler...

Reply Parent Score: 2