Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 70

Thread: Kolivas Pushes New Kernel Responsiveness Patches

  1. #21
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,763

    Default

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

  2. #22
    Join Date
    Jan 2009
    Posts
    117

    Default

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

  3. #23
    Join Date
    Nov 2009
    Posts
    60

    Default

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

  4. #24
    Join Date
    Nov 2009
    Posts
    60

    Default

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

  5. #25

    Default

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

  6. #26
    Join Date
    Dec 2008
    Posts
    315

    Default

    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.

  7. #27
    Join Date
    Nov 2009
    Posts
    60

    Default

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

  8. #28
    Join Date
    Jan 2008
    Posts
    772

    Default

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

  9. #29
    Join Date
    Jul 2008
    Posts
    1,712

    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.
    exactly! All that 'responsiveness' crap means nothing as long as copy'ing a file makes the mouse jerky!

  10. #30
    Join Date
    Mar 2009
    Location
    Portland
    Posts
    32

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

Posting Permissions

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