Reply With QuoteI'm reasonably sure the heavy I/O responsiveness patches are already in 2.6.36. I used one of the .36-rc's and it was phenomenal with large file operations.
Phoronix News Bot
The Linux 2.6.36 Kernel Is Now Out There
Phoronix: The Linux 2.6.36 Kernel Is Now Out There
The Linux 2.6.36 kernel is now out there on the Internet. After an unexpected delay and some other slowdowns in the 2.6.36 development cycle, Linus tagged the 2.6.36 kernel this afternoon...
http://www.phoronix.com/vr.php?view=ODY5NA
Senior Member
I'm reasonably sure the heavy I/O responsiveness patches are already in 2.6.36. I used one of the .36-rc's and it was phenomenal with large file operations.
Phoronix Member
Not all of them, the more untested were held back for 2.6.37.Originally Posted by etnlWings
Junior Member
No fanotify!
Fanotify system calls were pulled at the last minute over ABI concerns. See the release announcement.
Senior Member
Well that will be interesting, considering current performance (on relatively old hardware, even). I stand corrected.
Phoronix Member
Oh God please desktop responsiveness patches.
Senior Member
This seems to be the topic of the day, so here it goes once again:
Desktop responsiveness patches FTW \m/
Junior Member
typo: debuging should be debugging
Phoronix Member
I have been a Linux junky for many years. But recently I came across a data point which really baffled me for and put shameful dent in my pride of Linux.
At our company, one of the things that was forced down our throats were laptops with Windows 7 running. We had to use VMs to run Linux for our development.
Being a Linux zealot, I reversed the roles. Ran Linux on host and Windows 7 in VM. I noticed that just one Windows 7 VM running, with 1GB given to it, a project build (which is largish) can make the desktop completely unresponsive: mouse freezes, desktop can't be changed, Windows7 VM doesn't refresh its window etc. And this is with 2.6.36-rc7.
Reverse the roles, run 3 Linux VMs inside Windows 7 with 1GB of RAM each. Build the same project inside any of those VMs and everybody (the host as well as all the VMs) keeps chugging along nicely. And surprisingly, the build (which is pretty linear single thread) inside VM finished faster.
That hurt bad! Why is it that we can't find this bottleneck and fix it after so many years?
Phoronix Member
I have been a Linux junky for many years. But recently I came across a data point which really baffled me for and put shameful dent in my pride of Linux.
At our company, one of the things that was forced down our throats were laptops with Windows 7 running. We had to use VMs to run Linux for our development.
Being a Linux zealot, I reversed the roles. Ran Linux on host and Windows 7 in VM. I noticed that just one Windows 7 VM running, with 1GB given to it, a project build (which is largish) can make the desktop completely unresponsive: mouse freezes, desktop can't be changed, Windows7 VM doesn't refresh its window etc. And this is with 2.6.36-rc7.
Reverse the roles, run 3 Linux VMs inside Windows 7 with 1GB of RAM each. Build the same project inside any of those VMs and everybody (the host as well as all the VMs) keeps chugging along nicely. And surprisingly, the build (which is pretty linear single thread) inside VM finished faster.
Laptop has 4GB of RAM and Windows 7 (32-bit) sees only 3.4GB while Linux sees all 4GB of it, so technically Linux is working with more RAM.
That hurt bad! Why is it that we can't find this bottleneck and fix it after so many years?
