Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The state of linux IO scheduling for desktop?

pinkeen (1804300) writes | more than 3 years ago

Linux 2

pinkeen (1804300) writes "I am using linux as my work & play OS for 5+ years. The one thing that constantly drives me mad is its IO scheduling. When I'm copying a large amount of data in the background, everything else slows down to a crawl while the cpu utilization stays at 1-2%. The process which does the actual copying is highly prioritized in terms of I/O. This is completely inacceptable for a desktop OS. I've heard about the efforts of Con Kolivas and his Brainfuck Scheduler, but it's unsupported now and probably incompatible with latest kernels. Is there any way to fix this? How do you deal with this? I have a feeling that if this issue was to be fixed, the whole desktop would become way more snappier, even if you're not doing any heavy IO in the background."

cancel ×

2 comments

Sorry! There are no comments related to the filter you selected.

Agreed (0)

Anonymous Coward | more than 3 years ago | (#33997876)

i'm with you... i would think this would be something of a high priority for the kernel coders?

Really not all that much an OS can do about it (1)

m.dillon (147925) | more than 3 years ago | (#33998548)

Here's the problem. Scheduling READs is fairly easy, but the moment you mix disk writes into the equation everything goes to hell because the drive will instantly return a completion for a write until its internal caches reach whatever their dirty percentage limit is. It's virtually impossible to manage write bandwidth short of turning off the drive's caches and, of course, turning off the caches destroys write performance even under the best of conditions.

Without some way to query the cache status of the drive... for example, to determine how much dirty data has built up in the drive's caches and at what point the drive will stop instantly returning completions for writes... without some way to query that information the only way an OS to manage write bandwidth is to make some major guesses. And without some way to tell the drive how much media time you want to reserve for write operations the drive will happily do whatever the hell it wants, which usually winds up being highly destructive to performance in a mixed read/write environment.

Unfortunately this is also nearly impossible to get right. In fact it is impossible. The reason is that actual write bandwidth varies by several orders of magnitude depending on what read activity is occurring at the same, as well as on whatever seeking might be required. So throwing in some static or sysctl'd write bandwidth numbers to try to prevent stalls just doesn't work. Without some way to actually query the drive our hands are tied.

A secondary problem occurs when writes stall out... that is, when the drive is maxed out and write tags start to stall. These stalled writes tend to represent some degree of locked state in the filesystem and when they happen other parts of the filesystem can wind up blocking for long periods of time.

-Matt

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>