BFS Scheduler Lost Some Charm With Linux 3.11

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

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

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

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

[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

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