Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 70

Thread: Kolivas Pushes New Kernel Responsiveness Patches

  1. #11
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote 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.
    I think you should read the notes in the patches first

    The 10000Hz patch is not recommended:

    "There's some really badly broken software out there that is entirely dependant on HZ for its maximum performance. Raise the maximum HZ value to some higher and slightly unreasonable values up to some higher and completely obscene values.
    ...
    Being over 1000, driver breakage is likely."

    In other words, don't use it, unless you know what you are doing.

  2. #12

    Default

    Quote Originally Posted by RealNC View Post
    Who's talking about Firefox? The problem is more general. 2.6.32 introduced changes in its scheduler (actually inspired by BFS) to make things better. But still, BFS gives better results.
    Maybe for you, because I don't notice any problems not related to slow 2D. I also notice my Linux system is more responsive then Windows - in example on my older hardware sound was stuttering in Windows under load. Last time I tried BFS it was in rather terrible state - dying input, very low performance in games when listening to the music same time (however, according to change log this problem is solved in the newest version). It seems BFS fits better on some configurations, but there are/were big problems with it.

  3. #13
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by yoshi314 View Post
    i remember the argument about BFS performance back on lkml, which clearly showed that linux developers have little idea of things average users do on their desktops.
    I remember that too. I believe Ingo posted something about BFS not working well on his 64 core system (or something with way too many CPUs). CK got pretty pissed about that understandably.

  4. #14
    Join Date
    Nov 2007
    Posts
    315

    Default

    Quote 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.
    using 100kHz tick in a practical system is highly not recomended.
    This patch just provides more options with a max of 100kHz.
    Some old genetics patch in the love sources 5years back did a similar thing and the system becomes all but unusable above 10kHz (kernel spending more time switching context then letting processes do stuff...)

    I know I tried

  5. #15
    Join Date
    Mar 2009
    Posts
    10

    Default

    Quote Originally Posted by waucka View Post
    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.
    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.

  6. #16
    Join Date
    Jan 2009
    Posts
    206

    Default

    Quote 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!

  7. #17
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote 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.

  8. #18
    Join Date
    Sep 2009
    Posts
    20

    Default

    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.)

  9. #19
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote 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."

  10. #20
    Join Date
    Jul 2007
    Posts
    176

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •