BFS Scheduler Lost Some Charm With Linux 3.11

[lano1106]

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)

[silix]

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

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

[a user]

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

[lano1106]

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.

[halo9en]

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.

[movieman]

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.

[kertoxol]

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?

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.

[lano1106]

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.

[mark45]

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.

[curaga]

There has been some work, see:

https://github.com/stiletto/angrymlocker

http://vignatti.com/2007/07/17/xorg-input-thread-summary-or-something-2/