Live data from Hacker News

The ~200 Line Linux Kernel Patch That Does Wonders

phoronix.com

41–50 of 98 posts

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#41
post #38

Earlier quoted context omitted.

What kind of application blocks on disk IO but nothing else for extended amounts of time? I'm having a hard time seeing how installing an SSD and maxing out your cores are terribly related otherwise. SSDs do a lot to reduce loadtimes, and thus make your computer seem much faster, but they do little for making your programs run full-speed-ahead constantly. Most every application out there blocks on network connections…

"What kind of application blocks on disk IO but nothing else for extended amounts of time? I'm having a hard time seeing how installing an SSD and maxing out your cores are terribly related otherwise" Virtual memory paging to/from disk. This is probably why the new MacBook Airs feel faster than the CPU+RAM specs suggest.

That'll improve your loadtimes, but I'm having a really hard time seeing that as the reason why most people aren't maxing out their CPUs all the time. Unless something has gone terribly wrong, you should never be hitting your disk that much.

During standard home computer operation, both the CPU and the disk are generally quite idle.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#43
post #31

Earlier quoted context omitted.

It isn't hard to do, but a painless way to learn is to install a ubuntu 10.10 instance in a virtualbox and try it all in the box. If you screw up, who cares. After you have been through the process once it won't be intimidating to do it for your real OS.

One thing to consider in terms of building a new kernel is that repos tend to customize their release kernels quite a bit, by adding non-mainline patches, extra drivers, etc. Recompiling a vanilla kernel (from the linux-next git) is a pretty easy process, but you may find that when running it you've lost some nice features of the release you run or odd things have stopped working. One might get better results from us…

in ubuntu, the config used to compile the kernel is available at /boot/config-`uname -r`

copy it to the source dir and name it as .config

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#44
post #36

Earlier quoted context omitted.

yes, i'd like that very much but the current prices are too high for me.

You can afford a MacBook Pro but you can't afford an SSD that costs 25% of that? (A really fast expensive SSD is around $400.)

Bingo: if I used a MBP as my main computer, I'd take out the optical drive and put in something like this: http://eshop.macsales.com/shop/internal_storage/Mercury_Extr... for $99. Or the 60GB version for $149.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#45

It's not down for me... but here's the text: In recent weeks and months there has been quite a bit of work towards improving the responsiveness of the Linux desktop with some very significant milestones building up recently and new patches continuing to come. This work is greatly improving the experience of the Linux desktop when the computer is withstanding a great deal of CPU load and memory strain. Fortunately, th…

OT: is "make -j64" overkill unless you have dozens of cores or am I missing something?

The number of jobs to run for an optimal compile time can be quite confusing. If none of the files you are going to compile are cached it is alright to run a lot more jobs then usual as a lot of them are going to wait for the disk I/O. After that twice the jobs then you have cores is mostly appropriate.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#46

It's not down for me... but here's the text: In recent weeks and months there has been quite a bit of work towards improving the responsiveness of the Linux desktop with some very significant milestones building up recently and new patches continuing to come. This work is greatly improving the experience of the Linux desktop when the computer is withstanding a great deal of CPU load and memory strain. Fortunately, th…

OT: is "make -j64" overkill unless you have dozens of cores or am I missing something?

How many simultaneous threads will your next computer be able to run?

Chances are it already runs at least two, most probably four. It's not unreasonable to see 4 and 8-threads as the norm. Also keep in mind we are only considering x86s. SPARCs, IIRC, can do up to 64 on a single socket. ARM-based servers should follow a similar path.

BTW, a fully-comfigured MacPro does 12. A single-socket i7 machine can do 12. I never saw a dual-socket i7, but I have no reason to believe it's impossible.

Considering that, -j64 seems quite reasonable.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#47
post #31

Earlier quoted context omitted.

One thing to consider in terms of building a new kernel is that repos tend to customize their release kernels quite a bit, by adding non-mainline patches, extra drivers, etc. Recompiling a vanilla kernel (from the linux-next git) is a pretty easy process, but you may find that when running it you've lost some nice features of the release you run or odd things have stopped working. One might get better results from us…

in ubuntu, the config used to compile the kernel is available at /boot/config-`uname -r` copy it to the source dir and name it as .config

yup, but that gets you a clone of the configuration options - which is important - but doesn't include the source patches, reverts, backports etc. that ubuntu made to their release kernel. I haven't looked at 10.10 specifically, but there are likely a fair number of them - many vendors customize extensively and few (if any?) ship 100% vanilla.

It's often not a problem to replace a release kernel with a vanilla kernel, but it can definitely change some behaviors or bite you if you're a special case or are using drivers not in the kernel tree.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#48
post #24

I don't follow kernel development extremely closely, but it fascinates me that people are still actively working on the kernel's scheduler and achieving a "huge improvement" like this.

I remember reading something about an anesthesiologist who got into hacking the scheduler targeting desktop use cases. He generally said that the scheduler gets a lot more attention from people who care more about server work loads and such. He had his own custom kernel patches that people used to get directly from him that weren't in the mainstream kernel -- This was before the era of multi-core, but people said his…

Con Kolivas. He's also mentioned in the article.

http://en.wikipedia.org/wiki/Con_Kolivas

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#49
post #32
post #13

Earlier quoted context omitted.

What sort of tasks? FWIW, I had a similar configuration to yours (just an older MBP) and installing an SSD helped immensely . I can hit 200% CPU load and not even realize it until the fans kick in…

I know the subject is pretty much Apple's and oranges but i'm currently running: - Terminal with 2 tabs - firefox with 2 tabs - chrome with about 9 - gaim and skype - iTunes streaming soma.fm - Netbeans with an opened project - jEdit - Colloquy - Postgres instance and as soon as i booted Windows XP in VMware, well, took me a while to be able to reply to this post (after the vm settled). I also that you might be sayin…

Your typical workload sounds almost exactly the same to mine - right down to VMware temporarily killing OS X performance.

Not that Anonymous Guy On HN is worth much, but get an SSD - it'll be the best upgrade you've ever purchased.

(Or maybe I just needed to sidegrade to Linux. :)

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#50
It makes me wonder whether it is a sign that desktop responsiveness has been neglected by the kernel devs which possibly prioritize server issues. I had read a Google engineer suggesting Canonical should hire decent kernel developers : " P.S. Next thing for Ubuntu to learn --- how to pay their engineers well enough, and how to give them enough time to work on upstream issues, that once they gain that experience on Ubuntu's dime and become well known in the open source community, they don't end jumping ship to companies like Red Hat or Google. :-)"

http://news.ycombinator.com/item?id=1321029

Post reply on HN