I'm looking at the fact that by far, the thing slowing my system down the most is my hard drives. And looking at the specs of the newer hard drives, I'm not seeing any real advances in anything *BUT* capacity, and maybe in really large reads/writes.
But the myriad of little reads and writes from Gnome/KDE putting snippets of XML into individual files, the .cache directory, the web browser and it's plethora of relatively tiny files, the often-times widely scattered reads and writes of swap...
These are getting no loving what so ever. Meanwhile, everyone's saying just add RAM. Except my motherboard only goes up to 8GB of RAM, and I'm not so sure that's really going to improve things that much.
And I'm caching stuff that it doesn't seem to make sense to - multi-megabyte audio files, half-gigabyte and up video files - and once a program allocates itself some RAM, it *SURE* doesn't seem to want to give it up. (Of course, this is really hard to be sure of, because any long time linux user will tell you that the memory columns in ps don't really mean anything useful, and when you dig further - it's hard to be sure the *KERNEL* knows what memory belongs to who - although it does do a good job of cleaning up after the application crashes, so it knows *SOMETHING*.)
So why not a two-pronged approach. A file-system bit, like the sticky bit used to be to force caching of some kind (Linux nearly ignores it, apparently) - but to tell the kernel that said file is *NOT* to be cached. With /etc/ , /bin, etc all on a flash drive, there'd really be little reason to cache them, so you could mark them so - and you could also mark media files likewise, and not need to change the apps. There could be a flag for opening the file to force caching of it (though I'm not sure I can see why), allowing user space to handle things as it feels the need, but if it doesn't, the mostly right thing happens anyway. updatedb - would use the call to open *EVERYTHING* in non-caching mode, vlc wouldn't need to worry about it - could do its own limited caching it needs to operate - since it could assume media files wouldn't be cached if the user doesn't want them to be - while other programs could say cache it - even if it doesn't think it needs to be.
And for that matter - does the OOM killer create its own swap for some reason? I turned off swap a few minutes ago, after a reboot, opened some memory hogs, and when memory filled up (according to XOSview - I'm sure not the most accurate system meter, but it sure makes sense to me!), I got *MASSIVE* hard drive I/O, which pretty much tied the whole system into knots for well over 15 minutes (before I gave X it's version of the vulcan nerve pinch - took it another 5 to recognize *THAT*). What was the hard drive doing thrashing, since there was no designated swap for memory to be pushed off to temporarily?
I'm going to admit it here - I'm a Linux *USER*. I can - and have - done make clean ; make ; make install to build a kernel, or to install a program that didn't have a convenient package (and why can't I, as a user, install a package to *my* home directory, instead of having to go to root and install it system wide? I know, I wander off topic...) I just want a machine that runs nicely. The recent bit that does some kind of ulimiting per console (some kind of easy kernel patch, that someone else showed could be almost as easily done with a few lines in .bashrc ?) helped a fair bit - but still, every day I gnash my teeth as I wait for my hard drives to catch up with everything else.