The ~200 Line Linux Kernel Patch That Does Wonders

[droidhacker]

Would you two quit it? You're both right with respect to your own perspectives, and perspectives are NOT absolute -- everyone has a different one.

[zicada]

Guys, you do realize this patch only affects applications that run within a tty yea ? The desktop itsels is not affected at all. Only starting applications from a terminal while running something like make -j in a terminal speeds this up.

All the reports about the desktop itself being alot faster is just placebo unless the people in question where running a make -j64 or similar at the same time.

Compiling kernels all the time really isn't a very typical workload for most users, and it's a little silly that this isn't even mentioned in the original article.

[Decatf]

and to add more fuel to the fire the phoronix videos show a video playing stuttery then playing fine with the patch which has even led some people so far as to thinking this somehow gives their hardware a performance boost. The amount of people on Ubuntu Forums begging and begging for someone to compile a patched kernel for them is ridiculous.

[zicada]

Basically, unless you are a kernel developer who likes to listen to music, surf and watch videos while you're compiling, this patch does absolutely nothing. It would probably be a good idea to post an update to the original article pointing this out so that all the ubuntu njubs can calm down a tad.

[HokTar]

Well, the thing is that I don't compile stuff, but still sometimes I have huge I/O loads and then even the music stops and my cursor barely moves. If this could help in such cases that would be awesome.

I do not run the demanding stuff in terminal, so maybe nothing will change for me. That would be a pity...

[zicada]

Well, the thing is that I don't compile stuff, but still sometimes I have huge I/O loads and then even the music stops and my cursor barely moves. If this could help in such cases that would be awesome.

I do not run the demanding stuff in terminal, so maybe nothing will change for me. That would be a pity...

This patch doesn't apply to IO loads at all, only CPU. It is currently being discussed to add a similar patch to the kernel for automatically using cgroups for IO loads as well.

What's important to realize is that it was possible to do what this patch does for quite a while using cgroups. The issue has been that no distros really have made any use of it.

[HokTar]

This patch doesn't apply to IO loads at all, only CPU. It is currently being discussed to add a similar patch to the kernel for automatically using cgroups for IO loads as well.

What's important to realize is that it was possible to do what this patch does for quite a while using cgroups. The issue has been that no distros really have made any use of it.

Then I really don't get it. Why do people complain about bad responsiveness? I have no problems whatsoever if it's not I/O related.
My laptop is pretty fast and responsive even though I run Boinc (Einstein@home) all the time.
I mean I've never felt any difference if I paused Boinc, so no problems with the scheduler. Or is it just because Boinc has a constant "lowest" priority?

Am I missing something?

[ad_267]

Then I really don't get it. Why do people complain about bad responsiveness? I have no problems whatsoever if it's not I/O related.
My laptop is pretty fast and responsive even though I run Boinc (Einstein@home) all the time.
I mean I've never felt any difference if I paused Boinc, so no problems with the scheduler. Or is it just because Boinc has a constant "lowest" priority?

Am I missing something?

Well Boinc is running 64 processes at once as in the test case here.

The article on OMG Ubuntu about this is a bit of a joke, it makes it sound like this is some magic patch that makes Linux run 10 times faster normally.

[misiu_mp]

It is the IO load that is/was the problem in Linux. The ability of (an) IO-bound process(es) to starve a CPU-bound process when the latter needs to access a little of IO. You end up having two idle cpu cores wasting time waiting for IO, even though just a drop of IO more to the second process would utilize the full power of its processing units. That how it used to be able to happen, I've heard it's been addressed around 2.6.32. Didn't have the opportunity to check that.
There is only limited use in being able to vastly overload the cpu and still have a responsive system. Those scenarios does not happen that often but when they do, they are very annoying (and are not that uncommon in low-power systems). Now, with respect to IO (HDD), that's a different story - hdd's get overcommited all the time (less so with SSDs). It will be interesting to see that grouped.
Also, if you read the lkml thread, there seems to be a will to generalize this (possibly trough userspace), to be able to assign scheduling groups by name to programs at will, not necessarily bound to a tty.
This way you (the distros) could set certain programs to share a group and compete for cpu only within that group - no mater how they get started (one such group could be the build tools, another - image processing, or the desktop environment).
The tty binding is just a quick and simple, yet powerful solution that allows to test this feature.
I see quite some potential in this. Maybe linux will become the first 'always responsive' modern UI system. It makes image processing on a netbook possible. Will still take awfully long time, but you'll be able to forget about it while browsing or watching videos.
Also, since it improves the determinism of scheduling, it should help in some real-time-ish problems and on embedded systems.

[V!NCENT]

"This explains that you have absolutely no clue what "load" means It's not an absolute quantity like RAM or hard disk space"

actually it IS an absolute quantity, no matter what OS etc you advocate, right down at the core,you have a fixed amount of micro ticks in which to perform a given task, you can not perform more than this total load in a given time slice.

this is exactly where your scheduling for load comes in to it, you divide these limited ticks of time to move different parts of the sequentially run code to give the appearance of multitasking and responsiveness nothing more, so it is a absolute quantity.

Bingo! And that's why E17 (for example) runs so much faster than for example Gnome, simply because it uses the bare needed amount of instructions.

But in this day and age with 6 core i7 CPU's; it's also a matter of what's being done first and what is being done most. The scheduling is about what amount of instructions per time and what's first in line in time also contribute to the responsiveness ('x'-)factor.