Announcement

Collapse
No announcement yet.

BFS Scheduler Lost Some Charm With Linux 3.11

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

  • phoronix
    started a topic BFS Scheduler Lost Some Charm With Linux 3.11

    BFS Scheduler Lost Some Charm With Linux 3.11

    Phoronix: BFS Scheduler Lost Some Charm With Linux 3.11

    It appears that the out-of-tree BFS scheduler lost some of its charm with the Linux 3.11 kernel release where CFS is now running faster...

    http://www.phoronix.com/vr.php?view=MTUwNDI

  • lano1106
    replied
    Originally posted by silix View Post
    but the point is that CFS does NOT have constant execution times - it relies on a tree, and tree traversal times are logarithmic
    wo oh. this is a big statement. Do you have reference to back this statement? If this is true, that would means that the CFS devs are guilty of false representation.

    You cannot say that something is O(1) if it includes something have a logarithmic complexity.

    I know that CFS use lists but I am assuming that the number of lookups is constant or else CFS would be O(n)

    Leave a comment:


  • silix
    replied
    Originally posted by movieman View Post
    As suggested above, I suspect it's because Windows ties the GUI tightly to the rest of the operating system, while Linux runs it as a user space process.
    that was the case with XP 10 years ago... the window manager (DWM) is a userspace process relying on device management / arbitration from the kernel, starting with Vista

    Originally posted by a user
    assuming C denotes a constant then of course O(1) is the very same as O(C), by definition of O()
    O(1) is equivalent to O(constant) (in fact O(c) isnt used)

    but the point is that CFS does NOT have constant execution times - it relies on a tree, and tree traversal times are logarithmic

    Leave a comment:


  • a user
    replied
    Originally posted by lano1106 View Post
    In my mind O(1) is the same as O(C).
    assuming C denotes a constant then of course O(1) is the very same as O(C), by definition of O()

    Leave a comment:


  • lano1106
    replied
    Originally posted by halo9en View Post
    Since the multiqueue block layer in kernel 3.13 has reportedly increased system performance/responsiveness under I/O load, it would be very interesting to see benchmarks of 3.13 with and without BFS (whose purpose is to enhance system responsiveness). Even though ATM the new block layer is not performing too well.
    you must have meant BFQ and not BFS. but yes I agree. It would be interesting how BFQ perform with 3.13.

    Leave a comment:


  • halo9en
    replied
    Since the multiqueue block layer in kernel 3.13 has reportedly increased system performance/responsiveness under I/O load, it would be very interesting to see benchmarks of 3.13 with and without BFS (whose purpose is to enhance system responsiveness). Even though ATM the new block layer is not performing too well.
    Last edited by halo9en; 01-09-2014, 02:26 AM.

    Leave a comment:


  • movieman
    replied
    Originally posted by tiredoffglrx View Post
    It's interesting to see how Windows handles this. I must ask, though: Do you happen to know why Linux doesn't do the same? For me (a newbie to Linux, who has no idea of programming) this sounds simple enough to implement.
    As suggested above, I suspect it's because Windows ties the GUI tightly to the rest of the operating system, while Linux runs it as a user space process. I think the pointer code on Windows was called directly by an interrupt, or a thread triggered by the interrupt, but I'm not 100% certain of that. Linux probably has to go through a lot more layers to get it to the X server.

    Leave a comment:


  • kertoxol
    replied
    I have the same problem as some of you guys, CFS behaving bad with heavy IO workload, and as said by an user before, tweaking CFS with sysctl.conf could lead to improvements. I think to know why some people aren't experiencing this problem, the cause could be a distribution custom sysctl.conf with such settings already applied.

    So, why don't we compare our sysctl.conf files?

    Code:
    vm.swappiness = 1
    Isn't doing nothing because the system is swapping even with 500M/1G of memory cached, over 4GB... Obviously swapping kills responsiveness a lot, even more than moving data from/to usb storage drives.

    Leave a comment:


  • lano1106
    replied
    Originally posted by tiredoffglrx View Post
    It's interesting to see how Windows handles this. I must ask, though: Do you happen to know why Linux doesn't do the same? For me (a newbie to Linux, who has no idea of programming) this sounds simple enough to implement.
    BTW, I have seen the mouse cursor blocking without swapping. My best explanation is a totally different design philosophy between Windows and Linux.

    In Windows, the GUI subsystem is part of the OS. In Linux it is implemented as a user space process.

    In Windows, the GUI is possibly managed totally outside the scheduler maybe in part in the interrupt handlers themselves.

    In Linux, the GUI will be impacted by process scheduling. Possibly playing with the X server scheduling params could help with the mouse cursor issue.

    Leave a comment:


  • mark45
    replied
    Originally posted by DrYak View Post
    It's not even a "pathetic behaviour", its by design.

    With scheduler, you have a trade-off between performance and responsiveness.
    (One of the simplest way to understand: + lots of bla bla bla.
    This is one example of demagogy by pseudo-explanation like it the past when you had to compile your own driver the Linux fans tried to "explain" you how this is good for you, or that it's not a "problem" or can't be solved, or how Linux having a small market share is "good", or whatnot. It's like listening to liberal demagogy about the invisible hand of the market.

    Long story short, it's a bug (more likely a collection of bugs), happens randomly, but it's serious, hasn't been (fully) fixed, it's a problem.

    Leave a comment:

Working...
X