On Tue, 27 Sep 2011, Russell Coker wrote:
On Tue, 27 Sep 2011, Daniel Pittman <daniel@rimspace.net> wrote:
Yes, but do you care? The day to day performance difference approximates zero, and it has done for several years, for most practical purposes. You can tell the difference when it comes to compiling software in languages with highly efficient compilers (eg: not, generally, C or C++), and when doing extremely CPU intensive operations (3D rendering, encoding), but desktop stuff?
The main performance issue I have on DESKTOP tasks (as opposed to compiling, video processing, etc) is web browsing.
For that the difference between a Pentium-M 1.7GHz (like a P3) and a dual-core 64bit CPU wasn't that obvious - Mozilla is slow everywhere.
My server is a laptop with 4G of RAM. According to munin[1], its average IO service time is 1 second! Some IO tasks are quick, but on the whole it is very bogged down. Opera taking 1GB, mozilla taking 500MB, a bunch of xterms, and a gig of cache should all fit in that fine. Why then do so many tasks end up in a D state waiting for each other? I wonder if I have a rogue process doing extraneous fsync()s screwing up filesystem access? I already run mozilla with libeatmydata, because of the ill-conceived misinterpretation of POSIX file atomicity. The really weird thing is that according to vmstat, it is swapping a lot. The really really weird thing is that it, at any given moment, might have 300MB free, 900MB cached and/or buffered. That cache was allocated an hour ago when kaffeine was recording a show. Why on earth does it preferentially swap out currently used apps rather than cache I haven't accessed in an hour? /proc/.../*/swappiness is at the default 10. It's just getting worse and worse as I upgrade kernels. The other machines are at 2.6.32, which was bad enough, but 3.0 seems absolutely terrible at virtual memory management. I've had to echo 3 to /proc/sys/vm/drop_caches to temporarily clear up the thrashing. Obviously no one else is suffering from these issues, as otherwise people would be rioting on the streets. I wonder what is different about mine? Is it just that I'm trying to do desktop style usage on a laptop harddisk? It is 5400rpm from memory, and it can sustain 80MB/s when writing contiguously, but the seeks involved in swapping drag it down to 3MB/s or so. But that's all my desktops could ever do when swapping too. Now that I think of it, I think the VMM behaviour sucks on large machines too. We've currently got a case open at work with redhat, where a development webserver with 12G of RAM is filling up with cache to the point where order-1 allocations are failing. Just drop the frigging cache when there's memory pressure or fragmentation for fscks sake! See also: http://tau-iota-mu-c.livejournal.com/172693.html (and no, I had to give up on zram in the end, because the compression was still too slow. I've just bought an extra 4G of ram. ark.intel.com tells me my chipset won't support it, but plenty of people on the web say it will actually work, and others say 8G total doesn't work, but 6G does. I guess we'll find out!) [1] Of course, I can't run munin all the time, because every 5 minutes it fires up and tries to allocate 3 processes that take 20MB of ram each. Apparently that's too much for my poor widdle machine with 4GB of ram, and it dives back into swap (instead of you know, dropping some of the 800MB of cache). Regularly as cronwork^Wclockwork. -- Tim Connors