Announcement

Collapse
No announcement yet.

Kolivas Pushes New Kernel Responsiveness Patches

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by realnc View Post
    i'm using bfs almost since it came out. Without it, linux here is much worse than windows in gui responsiveness. With bfs it's almost on-par.
    +123456789, amen brother . I want to BFS merged this time!

    Comment


    • #17
      Originally posted by hax0r View Post
      +123456789, amen brother . I want to BFS merged this time!
      It will probably never be merged. The majority of the kernel devs agreed that there won't be more than one CPU scheduler in the kernel.

      Comment


      • #18
        Lagginess under heavy disk access is like the original sin of the Linux kernel. I'm guessing it's something structural, because if it were easy to fix they'd have fixed it by now, right? They can't be that out of touch?

        Anyway, it's ridiculous that I'm playing Slime Volleyball (simple game in a Java applet in a web page), and if updatedb starts up in the background suddenly the whole thing lags to hell and I lose. Windows doesn't do this kind of thing. Under Windows you can start some kind of task which does heavy disk access and let it run in the background, and you don't notice it. Under Linux, whenever I notice stuff is being laggy, I look down at the status LEDs, and yep, something is invariably hammering the disk. Every time.

        I bet people wouldn't have been nearly as peeved, for example, at KDE4's background disk indexing service if the kernel weren't so awful on this front. But under Linux you just can't do anything disk intensive in the "background" no matter how much niceness you give it, because it'll lag everything in the foreground to hell and back anyways.

        (To be fair, things have gotten somewhat better - I can't remember the last time I had music skip because of, well, anything. I don't know if that's a scheduler thing or a disk thing or both, but either way it's very good. Still, there's a long way to go.)

        Comment


        • #19
          Originally posted by illissius View Post
          Under Linux, whenever I notice stuff is being laggy, I look down at the status LEDs, and yep, something is invariably hammering the disk. Every time.

          I bet people wouldn't have been nearly as peeved, for example, at KDE4's background disk indexing service if the kernel weren't so awful on this front.
          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."

          Comment


          • #20
            I agree, same here. Whenever there is disk I/O, the system, especially firefox literally crawls . And yes, things have improved and improved a lot ever since I have been using Linux (about 7 years ago), but I think, it is more because of better hardware.

            So how do Windows and OSX do well? (Actually, OSX struggles quite a bit too. Damn 'mdworker'.) Surely then, they must be doing slower I/O. Of course I wouldn't mind that for background processes. Is it done in the kernel or the applications are written that way? I am sure there should be a way to set disk I/O priority for individual processes in Linux.

            Comment


            • #21
              Originally posted by hdas View Post
              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."

              Comment


              • #22
                Originally posted by RealNC View Post
                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)

                Comment


                • #23
                  Originally posted by RealNC View Post
                  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).

                  Comment


                  • #24
                    Originally posted by RealNC View Post
                    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).

                    Comment


                    • #25
                      Originally posted by drees View Post
                      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).

                      Comment


                      • #26
                        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.

                        Comment


                        • #27
                          Originally posted by Hephasteus View Post
                          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).

                          Comment


                          • #28
                            Originally posted by Hephasteus View Post
                            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...

                            Comment


                            • #29
                              Originally posted by waucka View Post
                              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!

                              Comment


                              • #30
                                10.000Hz ? HZ is no longer really user visible

                                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.

                                Comment

                                Working...
                                X