Forgot your password?
typodupeerror
Linux

The State of Linux IO Scheduling For the Desktop? 472

Posted by timothy
from the in-and-out-and-in-and-out dept.
pinkeen writes "I've used 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 unacceptable 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." Update: 10/23 22:06 GMT by T : As reader ehntoo points out in the discussion below, contrary to the submitter's impression, "Con Kolivas is still actively working on BFS, it's not unsupported. He's even got a patch for 2.6.36, which was only released on the 20th. He's also got a patchset out that I use on all my desktops which includes a bunch of tweaks for desktop use." Thanks to ehntoo, and hat tip to Bill Huey.
This discussion has been archived. No new comments can be posted.

The State of Linux IO Scheduling For the Desktop?

Comments Filter:
  • It sucks I agree (Score:4, Interesting)

    by Anonymous Coward on Saturday October 23, 2010 @02:40PM (#33997908)

    This issue got so bad for me I switched to FreeBSD.

    • by Anonymous Coward on Saturday October 23, 2010 @03:06PM (#33998128)

      We switched our dedicated web servers from Linux to FreeBSD and OpenSolaris. When we upload videos (usually 10GB or larger) over our 100Mbps internet connection to the server, or a client was downloading the videos, those who were accessing the server using the web server complained it took seconds serve each web page. The videos were on a magnetic hard drives, the OS and web server was on SSDs (which was mirrored in RAM). Server logs were fine, CPU utilisation was low, the servers have 1Gbps connection. We put it down to I/O scheduling. Switching the OS solved the problems.

      • Re: (Score:3, Informative)

        by dogsbreath (730413)

        Solaris is still a terrific operating system. Every version has made advances in stability and performance, particularly with disk and network i/o. SMP, threading are very mature as well.

        I doubt that Oracle will be able to do anything with it except bury it. Too bad.

    • Re:It sucks I agree (Score:5, Interesting)

      by ObsessiveMathsFreak (773371) <obsessivemathsfreak@@@eircom...net> on Saturday October 23, 2010 @03:13PM (#33998198) Homepage Journal

      This is the number one problem with all Linux installations I have ever used. The problem is most noticeable in Ubuntu where, any time one of the frequent update/tracker programs runs, the entire system will become all but unusable for several minutes.

      I don't know if it's all that related, but swap slowdown is an appalling issue as well. If a single program spikes in RAM usage, I often have to reboot the whole system as it hangs indefinitely. As I work with Octave a lot, often a script will gobble up a few hundred megs of memory and push the system into swap. Once that happens, it's often too late to do anything about it as programs simply will not respond.

      • Re:It sucks I agree (Score:4, Interesting)

        by Lord Byron II (671689) on Saturday October 23, 2010 @03:22PM (#33998266)

        That's exactly why I stopped using swap a couple of years ago. On my main machine I have 3 GB and I feel that if I reach the limit on that, then whatever program is running is probably a lost cause anyway. The next malloc/new causes the program to crash, saving the system.

      • Re:It sucks I agree (Score:4, Informative)

        by Anonymous Coward on Saturday October 23, 2010 @03:43PM (#33998412)

        swapoff -a && swapon -a

        will force everything back into memory

        • Re: (Score:3, Insightful)

          by pegdhcp (1158827)

          swapoff -a && swapon -a

          will force everything back into memory

          Exactly, and it is a very good solution when things get out of hand. At least once or twice a month I recycle swap in order to prevent an imminent freeze. Maybe every 4 or 5 months I lost the system state for I/O scheduling problems on my desktop. On the other hand, my servers usually reboot only during power maintenances and/or fried hardware cases...

      • Re:It sucks I agree (Score:4, Informative)

        by shellbeach (610559) on Sunday October 24, 2010 @08:48AM (#34003272)

        I don't know if it's all that related, but swap slowdown is an appalling issue as well. If a single program spikes in RAM usage, I often have to reboot the whole system as it hangs indefinitely. As I work with Octave a lot, often a script will gobble up a few hundred megs of memory and push the system into swap. Once that happens, it's often too late to do anything about it as programs simply will not respond.

        I'm surprised you're seeing this with a process taking up a few hundred Mb -- that suggests to me that you have very little RAM in your system. But if it really is the kernel's fault for being more swappy than it should be, doing something like

        echo 10 > /proc/sys/vm/swappiness

        (as root) should fix your problems fine. (Swappiness can be a value between 0 and 100; 0 means never swap out, 100 means swap out all the time; 60 is generally the default value). See Ubuntu's swap FAQ [ubuntu.com] for lots more info.

        Of course, if you simply don't have enough memory in your system to support the RAM-intensive process and basic system functions, buying more memory might be the best solution ... :)

    • Re: (Score:3, Informative)

      by lsllll (830002)
      Such drastic change! I have seen this happen on numerous systems and I just change the elevator to "deadline" and poof! The problem is gone. See this discussion [launchpad.net] for some details. The CFQ scheduler is great for a Linux server running a database, but it completely sucks for desktop or any server used to write large files to.
      • Re:It sucks I agree (Score:5, Informative)

        by ChipMonk (711367) on Saturday October 23, 2010 @04:42PM (#33998910) Journal
        It's more than that. Since most Linux systems use ext{2,3,4}, CFQ is designed to behave very well with them. However, XFS and JFS do better with deadline or no-op. In fact, on my Athlon 64 X2 w/ 4G RAM, using XFS and CFQ at 2.5GHz did worse than XFS and deadline at 1GHz. Yes, CFQ and XFS clash that badly.

        (Site pimp: I did some of my own testing, and reported on it here [typepad.com]. I also provide basic shell scripts, so others can do their own tests.)
      • Re:It sucks I agree (Score:5, Informative)

        by Ingo Molnar (206899) on Sunday October 24, 2010 @05:02AM (#34002440) Homepage

        Such drastic change! I have seen this happen on numerous systems and I just change the elevator to "deadline" and poof! The problem is gone. See this discussion [launchpad.net] for some details. The CFQ scheduler is great for a Linux server running a database, but it completely sucks for desktop or any server used to write large files to.

        I see that the bug entry you referred to contains measurements from early 2010, at which point Ubuntu was using v2.6.31-ish kernels IIRC. (and that's the kernel version that is being referred to in the bug entry as well.)

        A lot of work has gone into this area in the past 1-2 years, and v2.6.33 is the first kernel version where you should see the improvements. Slashdot reported on that controversy as well [slashdot.org].

        If you can still reproduce interactivity problems during large file copies with CFQ on v2.6.36 (and it goes away when you switch the IO scheduler to deadline), please report it to linux-kernel@vger.kernel.org so that it can be fixed ASAP. (You can also mail me directly, i'll forward it to the right list and people.)

        Thanks,

        Ingo

  • by StripedCow (776465) on Saturday October 23, 2010 @02:41PM (#33997922)

    Isn't this also relevant when using Linux on a server? I mean, if one process or thread is copying a large file, you don't want your server to come to a crawl.

    It doesn't sound like just a "desktop" issue to me.

    • I use linux for desktop and servers. Never saw noticed the issue OP is referring to... maybe OP could be a little more specific about what he's doing and on which hardware?
      • Re: (Score:3, Interesting)

        by Lord Byron II (671689)

        It's been a big issue for me. Go to a directory with a couple of large files (say a dvd rip) and do a "cat * > newfile". Watch your system come to a crawl.

        • by joaosantos (1519241) on Saturday October 23, 2010 @03:34PM (#33998350) Homepage
          I just did it and didn't notice any slowdown.
        • by ksandom (718283) on Saturday October 23, 2010 @04:21PM (#33998738) Homepage
          Sorry dude, it looks like it's a hardware specific problem. I did that on nearly 700G of large files and then fired up the flight sim while it was still going. The only slow down was on file related activity, which is totally what you'd expect. I had it running full screen across two monitors without any drop in frame rate. AND I'm using economy hardware.
          • by Ingo Molnar (206899) on Sunday October 24, 2010 @04:38AM (#34002338) Homepage

            Sorry dude, it looks like it's a hardware specific problem. I did that on nearly 700G of large files and then fired up the flight sim while it was still going. The only slow down was on file related activity, which is totally what you'd expect. I had it running full screen across two monitors without any drop in frame rate. AND I'm using economy hardware.

            It may also be kernel version dependent - with older kernels still showing this bug.

            A lot of work has gone into the Linux kernel in the past 2 years to improve this area - and yes, i think much of the criticism from those who have met this bug and were annoyed by it was fundamentally justified - this bug was real and it should have been fixed sooner.

            Kernels post v2.6.33 ought to be much better - with v2.6.36 bringing another set of improvements in this area. The fixes were all over the place: IO scheduler, VM and filesystem code and few of them were simple.

            This Slashdot article from 1.5 years ago [slashdot.org] shows when more attention was raised to this category of Linux interactivity bugs.

            Thanks,

            Ingo

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      On IO intensive server: this is also a real issue. 20-30% of processors and cores stuck with a 99% iowait for hours, while the rest tries to cope. Total CPU load does not go above 20%. No solution yet after months of study and experimenting. Linux is indeed really bad at IO scheduling in general, it seems.

      Notw think of that situation and a heavy database system. A no-no solution.

    • by Anonymous Coward on Saturday October 23, 2010 @02:55PM (#33998030)

      There are some interactive-response fixes queued up for 2.6.37 that may help (a lot!) with this stuff.
      Start reading here: http://www.phoronix.com/scan.php?page=news_item&px=ODU0OQ

      • Re: (Score:3, Interesting)

        by man_of_mr_e (217855)

        How does this happen? Every year it seems I read about how this problem has been fixed in the latest kernel, and then it's like those fixes mysterious vanish?

      • by Ingo Molnar (206899) on Saturday October 23, 2010 @04:33PM (#33998846) Homepage

        I think the Phoronix article you linked to is confusing the IO scheduler and the VM (both of which can cause many seconds of unwanted delays during GUI operations) with the CPU scheduler.

        The CPU scheduler patch referenced in the Phoronix article deals with delays experienced during high CPU loads - a dozen or more tasks running at once and all burning CPU time actively. Delays of up to 45 milliseconds were reported and they were fixed to be as low as 29 milliseconds.

        Also, that scheduler fix is not a v2.6.37 item: i have merged a slightly different version and sent it to Linus, so it's included in v2.6.36 already: you can see the commit here [herehttp].

        If you are seeing human-perceptible delays - especially in the 'several seconds' time scale, then they are quite likely not related to the CPU scheduler (unless you are running some extreme workload) but more likely to the CFQ IO scheduler or to the VM cache management policies.

        In the CPU scheduler we usually deal with milliseconds-level delays and unfairnesses - which rarely raise up to the level of human perception.

        Sometimes, if you are really sensitive to smooth scheduling, can see those kinds of effects visually via 'game smoothness' or perhaps 'Firefox scrolling smoothness' - but anything on the 'several seconds' timescale on a typical Linux desktop has to have some connection with IO.

        Thanks,

        Ingo

    • Re: (Score:2, Interesting)

      by fishbowl (7759)

      This problem is highly visible in VMs. When you have one VM doing write-heavy disk IO, the other VMs suffer.

      I don't think it's a Linux problem as much as a general problem of the compromises that must be made by any scheduling algorithm.

      What about you Linux mainframe guys? You have unbeatable IO subsystems. Do you see the same problems?

  • by larry bagina (561269) on Saturday October 23, 2010 @02:43PM (#33997928) Journal
    have you tried ionice?
    • by atrimtab (247656) on Saturday October 23, 2010 @03:01PM (#33998080)

      ionice works great in a terminal window, but isn't integrated into any of the Desktop GUIs.

      I suppose you could prefix the various file transfer commands used by the GUI with an added "ionice -c 3", but I haven't bothered to look.

      Using ionice to lower the i/o priority of various portions of MythTV like mythcommflag, mythtranscode, etc. can make it quite snappy.

      • by JohnFluxx (413620) on Saturday October 23, 2010 @05:35PM (#33999276)

        Poor me! I added ionice integration into KDE since pretty much the dawn of time.

        In KDE, just press ctrl+esc to bring up my System Activity, right click on a process, then chose renice. You get a really pretty (imho heh) dialog letting you change the CPU or hard disk priority, scheduler, and so on.

    • I often note that multiple simultaneous low-priority file copies implemented as:

      ionice -c 3 rsync bigfilein directoryout

      run faster than multiple simultaneous high-priority copies implemented as:

      rsync bigfilein directoryout

      If the copies are run one at a time, the higher priority rsync runs faster. For multiple copies, often the lower priority rsyncs run faster. Also, desktop usability is much improved with the lower priority rsyncs.

      I suspect a priority inversion occurs inside the file systems write

  • by Anonymous Coward on Saturday October 23, 2010 @02:44PM (#33997934)

    ..download and compile the 2.6.36 kernel. A feature of the changes can be found at http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-36-1103009.html

    A very very easy to follow guide can be found at http://kernel.net/articles/how-to-compile-linux-kernel.html

    Sidenote - What is up with not being able to paste links? That's annoying.

  • by ehntoo (1692256) on Saturday October 23, 2010 @02:44PM (#33997938)
    Con Kolivas is still actively working on BFS, it's not unsupported. He's even got a patch for 2.6.36, which was only released on the 20th. http://ck.kolivas.org/patches/bfs/ [kolivas.org] He's also got a patchset out that I use on all my desktops which includes a bunch of tweaks for desktop use. http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/ [kernel.org]
  • by Animats (122034) on Saturday October 23, 2010 @02:49PM (#33997980) Homepage

    If the CPU utilization is that low, it's an I/O scheduling problem. See Linux I/O scheduling [linuxjournal.com].

    The CFQ scheduler is supposed to be a fair queuing system across processes, so you shouldn't have a starvation problem. Are you thrashing the virtual memory system? How much I/O is going into swapping. (Really, today you shouldn't have any swapping; RAM is too cheap and disk is too slow.)

    • by Khyber (864651)

      "RAM is too cheap and disk is too slow"

      Your disks might be too slow, but OUM-based MLC flash drives are so fast most current SSDs would look like 80's tech.

      • Re: (Score:3, Insightful)

        by julesh (229690)

        Your disks might be too slow, but OUM-based MLC flash drives are so fast most current SSDs would look like 80's tech.

        MLC flash has a life cycle of only around 10,000 writes, though, which for swap is way too small to be useful. Your lifespan on that SSD is likely to be only a couple of years, or even less for demanding applications, and the pricing on them is still high enough that DRAM isn't actually that much more expensive (I see about $4/GB for SSDs compared to about $16/GB for DRAM), at which point mo

        • Re: (Score:3, Informative)

          by Khyber (864651)

          OUM MLC is FAR different than anything in typical use.

          Try 10^8 read/write.

  • Using Mandriva 2010.0 (or on any earlier builds for that matter). Not sure if their stock kernel is using scheduling patches or not but the only time I've ever seen slowdowns on my wimpy P4 machine is with really serious oversubscribing to memory, which obvious will turn it into a dog. IO seems to have little to no effect however.

    So maybe you just need a better desktop distribution? A newer one perhaps? Don't expect that if you slap just any old distro on a machine and call it a workstation that you get som

    • Re: (Score:3, Informative)

      by frisket (149522)
      I'm using Ubuntu 10.4 on an old Dell and big copies don't seem to slow it down any more than I'd expect on an old machine, either when copying to an external USB backup (with rsync) or over the net to my office systems (via scp). Serious slowdown would seem to indicate something deeper is wrong.
  • by mrjb (547783) on Saturday October 23, 2010 @02:56PM (#33998042)
    I've wondered on occasion if this problem is really only due to scheduling. After all, most of us still write our file access code more or less as follows: x=fopen('somefilename'); while ( !eof(x)) { print readln(x,1024); /* ---- */ } fclose(x); Point being, there's nothing that tells the marked line that the process should gracefully go to sleep while the drive is doing its thing, and there's no callback vector defined either- nothing that indicates we're dealing with non-blocking I/O. I'd like to think that our compilers have silently been improved to hide those implementation details from us, but I have no proof that this is the case. Unless the system functions use some dirty stack manipulation voodoo to extract the return address of the function and use that as callback vector?
    • by Anonymous Coward on Saturday October 23, 2010 @03:06PM (#33998120)

      The kernel will preempt the process calling "readln", in other words putting it to sleep.
      The kernel will make sure the I/O happens, allowing other processes to work at the same time.
      You only need non-blocking code if your own process needs to other things at the same time.

    • by Anonymous Coward on Saturday October 23, 2010 @03:07PM (#33998140)

      The process will go to sleep inside the read() system call (inside readln() somewhere presumably). Other processes will be able to run in the meantime. It works by interrupting into kernel code, and the kernel changes the stack pointer (and program counter, and lots of other registers) to that of another process. When the data comes back from the disk, the kernel will consult its tables and see that your process is runnable again, and when the scheduler decides it's its turn, in a timer interrupt, the stack pointer will be switched back to your stack. (So yes, dirty stack manipulation voodoo.) Every modern OS works this way.

      • by Ingo Molnar (206899) on Saturday October 23, 2010 @03:55PM (#33998502) Homepage

        Yes. Here there is another problem at play: cp reads in the whole (big) file and then writes it out. This brings the whole file into the Linux pagecache (file cache).

        That, if the VM is not fully detecting that linear copy correctly, can blow a lot of useful app data (all cached) out of the pagecache. That in turn has to be read back once you click within Firefox, etc. - which generates IO and is a few orders of magnitude slower than reading the cached copy. That such data tends to be fragmented (all around on the disk in various small files) and that there is a large copy going on does not help either.

        Catastrophic slowdowns on the desktop are typically such combined 'perfect storms' between multiple kernel subsystems. (for that reason they also tend to be the hardest ones to fix.)

        It would be useful if /bin/cp explicitly dropped use-once data that it reads into the pagecache - there are syscalls for that.

        And yes, we'd very much like to fix such slowdowns via heuristics as well (detecting large sequential IO and not letting it poison the existing cache), so good bugreports and reproducing testcases sent to linux-kernel@vger.kernel.org and people willing to try out experimental kernel patches would definitely be welcome.

        Thanks,

        Ingo

    • Depending on the drive, sometimes application behavior can be an issue. A program that calls fwrite 1024 times with a kilobyte buffer will act quite differently to one that calls it just once with a megabyte buffer. The former will promote fragmentation, and often cause the drive to thrash around (unless it's an SSD) if there is other IO going on simutainously, which really kills performance. A single large write completes faster than a thousand small ones.
    • ... nothing that indicates we're dealing with non-blocking I/O ...

      Because it typically isn't non-blocking IO. The process can obviously request non-blocking, but the default (and most used) is blocking. So the process actually will sleep as it is supposed to if it's written correctly. It would not be the kernel's fault if a process requests a non-blocking fd and enters into a tight loop which spends more time looping than writing.

    • by WetCat (558132)

      Hm. I afraid you are not correct.
      When in this part of code "drive is doing its thing" ?I
      It happens only in readln () and in readln process yields control to the kernel, which is doing scheduling and io.
        So it's up to kernel what to do in this case.

  • Supposedly the 2.6.36 kernel addresses this issue. I don't know if the problem has been completely fixed, or mostly fixed, or what, since I haven't tried that kernel yet (too bad there isn't an easy way to install kernels in a cross-distro fashion!).

    Read the bullet points here, particularly the ones in the middle, as there has been multiple things done to this kernel to improve performance:
    http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-36-1103009.html?page=6 [h-online.com]
  • i just run it and let it own the computer for whatever time it takes = anywhere from 10 to 30 minutes, and just walk off, maybe go get a fresh cup of coffee or cold beer depending on where i am and what time of day it is. one thing i dont want is a borked copy because i was too impatient to let it do its job.
    • by eldepeche (854916) on Saturday October 23, 2010 @03:44PM (#33998428)

      I would definitely ditch an OS that fucked up a file copy because I used the computer for something else while I was waiting.

  • by guacamole (24270) on Saturday October 23, 2010 @03:07PM (#33998142)

    I can remember that even as far back as 1999 I saw this issue with Linux. This is not bad only for the desktop, but also for the server. I have also experience with Solaris workstations and servers, and it usually doesn't behave this way.

  • This is not a thread scheduling issue, it's a disk scheduling issue. If CPU utilization is only 1-2% and things aren't snappy then the issue is because the foreground process's I/Os aren't given higher (high enough?) priority. Easy enough to believe too, a whole lot of writes get cached and then queued up. With an elevator algorithm they'll likely all get performed before any reads required by the foreground process.

  • OS/2 (Score:2, Interesting)

    by picross (196866)

    I remember using OS/2 (IBM's desktop OS) and i was always amazed that you could format a floppy and do other tasks like nothing else was going on. I never did understand why that never seemed to make it into the mainstream.

  • Wrong Question (Score:3, Interesting)

    by donscarletti (569232) on Saturday October 23, 2010 @03:12PM (#33998188)

    This is not a case of Linux IO schedulers being unsuitable for the desktop, but more a case of desktop applications being written in a horrendous way in terms of data access. The general pattern being to open up a file object, load in a few hundred kilobytes, processing this then asking the operating system for more. This is a small inefficiency when the resource is doing nothing, but if the disk is actually busy, then it will probably be doing something else by the time you ask for it to read a little bit more. Not to mention the habit of reading through a few hundred resource files one at a time in seemingly random order, and blocking every time it reads, because the application programmer is too lazy to think about what resources the app is using.

    Linux has such a nice implementation of mmap, which works by letting Linux actually know ahead of time what files you are interested in and managing them itself, without the application programmer worrying his pretty little head over it. Other options are running multiple non-blocking reads at the same time and loading the right amount of data and the right files to begin with.

    The best thing about a simple CSCAN algorithm is that it gives applications what they asked for and if the application doesn't know what it wants, well, that's hardly a system issue.

  • by crlf (131465) on Saturday October 23, 2010 @03:13PM (#33998192)

    This is almost certainly not the IO scheduler's problem. IO scheduling priorities are orthogonal to CPU scheduling priorities.

    What you are likely running into is the dirty_ratio limits. In Linux, there is a memory threshold for "dirty memory" (memory that is destined to be written out to disk), that once crossed, will cause symptoms like you've described. The dirty_ratio values can be tuned via /proc, but beware that the kernel will internally add its own heuristics to the values you've plugged in.

    When the threshold is crossed, in an attempt to "slow down the dirtiers", the Linux kernel will penalized (in rate-limited fashion) any and every task on the system that tries to allocate a page. This allocation may be in response to userland needing a new page, but it can also occur if the kernel is allocating memory for internal data structures in response to a system call the process did. When this happens, the kernel will force that allocating thread (again, rate-limited) to take part in the flushing process, under the (misguided) assumption that whoever is allocating a lot of memory is the same thread that is dirtying a lot of memory.

    There are a couple ways to work around this problem (which is very typical when copying large amounts of data). For one, the copying process can be fixed to rate limit itself, and to synchronously flush data at some reasonable interval. Another way that a system administrator can manage this sort of task (if automated of course) is to use Linux's support for memory controllers which essentially isolates the memory subsystem performance between tasks. Unfortunately, it's support is still incomplete and I don't know of any popular distributions that automate this cgroup subsystem's use.

    Either way, it is very unlikely to be the IO scheduler.

    • Re: (Score:3, Insightful)

      by 0123456 (636235)

      Then there are programs like Firefox, which continually write to sqlite databases, which causes multiple fsync() calls, which will flush the disk cache each time if you're running on an ext3 filesystem. All because NTFS used to eat your bookmarks file if Windows crashed.

  • by Ingo Molnar (206899) on Saturday October 23, 2010 @03:32PM (#33998342) Homepage

    FYI, the IO scheduler and the CPU scheduler are two completely different beasts.

    The IO scheduler lives in block/cfq-iosched.c and is maintained by Jens Axboe, while the CPU scheduler lives in kernel/sched*.c and is maintained by Peter Zijlstra and myself.

    The CPU scheduler decides the order of how application code is executed on CPUs (and because a CPU can run only one app at a time the scheduler switches between apps back and forth quickly, giving the grand illusion of all apps running at once) - while the IO scheduler decides how IO requests (issued by apps) reading from (or writing to) disks are ordered.

    The two schedulers are very different in nature, but both can indeed cause similar looking bad symptoms on the desktop though - which is one of the reasons why people keep mixing them up.

    If you see problems while copying big files then there's a fair chance that it's an IO scheduler problem (ionice might help you there, or block cgroups).

    I'd like to note for the sake of completeness that the two kinds of symptoms are not always totally separate: sometimes problems during IO workloads were caused by the CPU scheduler. It's relatively rare though.

    Analysing (and fixing ;-) such problems is generally a difficult task. You should mail your bug description to linux-kernel@vger.kernel.org and you will probably be asked there to perform a trace so that we can see where the delays are coming from.

    On a related note i think one could make a fairly strong argument that there should be more coupling between the IO scheduler and the CPU scheduler, to help common desktop usecases.

    Incidentally there is a fairly recent feature submission by Mike Galbraith that extends the (CPU) scheduler with a new feature which adds the ability to group tasks more intelligently: see Mike's auto-group scheduler patch [kernel.org]

    This feature uses cgroups for block IO requests as well.

    You might want to give it a try, it might improve your large-copy workload latencies significantly. Please mail bug (or success) reports to Mike, Peter or me.

    You need to apply the above patch on top of Linus's very latest tree, or on top of the scheduler development tree (which includes Linus's latest), which can be found in the -tip tree [redhat.com]

    (Continuing this discussion over email is probably more efficient.)

    Thanks,

    Ingo

  • by grandpa-geek (981017) on Saturday October 23, 2010 @05:47PM (#33999394)

    I've encountered situations where I'm trying to do something online and a task starts up due to a cron job that builds some kind of index. The index building should be in the background but somehow takes priority over what I'm doing on the desktop. Those kinds of cron jobs should be default scheduled in the background, not take priority over what is happening on the desktop.

Forty two.

Working...