Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 20 Oct 2007 11:35:35 +0200:
> i have a notebook that i usually shut down more than 3-4 times/day and > the chache problem for me is fundamental. i don't have to wait for > portage almost 7minutes for a world preview update while paludis does > it in less than 2min. With mainline kernel suspend-to-disk working, and setting /sys/power/ image_size to the largest possible given the size of the swap partition, I've discovered that cache is retained up to that size. The default size if nothing is written to image_size is only 500 MB, enough to do a decent job of suspending what's running, but not enough to really get much if any cache. However, my swap setup is four partitions of 4 gigs each, each on different drives and with the priority set equal on all four, so the kernel will stripe across all four automatically, thus speeding swap activity dramatically over what it would be with just a single disk. Since the suspend image must be on a single kernel device (and while swap works on combined devices such as RAID, suspend doesn't seem to, even when said devices are assembled from kernel mode directly, before user mode is invoked), that limits me to using a single 4 gig image. More precisely, I can see the active swap devices in /proc/swaps along with their size, and set /sys/power/image_size to the precise swap size in KB shown there for my chosen device, that being 3909 MB (so slightly less than 4 GB) here. With a just under 4 GB suspend image size, it's actually roomy enough to retain a decent amount of cache (not all, since I've 8 gigs of memory, but dramatically more than the 500 MB default, that's for sure!), and the cached info from my Gentoo tree and overlays, plus that from the package database, portage config, and world files, is much less than that, significantly less than a gig. In fact, unless I've been copying 5 GB DVD images around or some such, just under 4 GB is quite enough to cache my entire file access profile from boot up thru my normally loaded X and normal working set of apps, and including a routine emerge --update -- deep --newuse world run. Thus, with a suitable suspend image size, even suspend to disk, and even using the mainline kernel suspend code (no fancy susp2 sources required, tho I'm told it's even /more/ efficient at maintaining cache), maintaining cache isn't a big deal. For the most part, it "just works", once image_size is set correctly. Of course, with that big a suspend image, wakeup times are dramatically longer, since it has to read all that extra data back in off of disk. However, it's definitely worth it, since I get back a fully responsive system, not one with virtually no cache, that has to read everything back in before it can actually do anything. So... I'd suggest you investigate /proc/swaps and write an appropriate image size to /sys/power/image_size. Assuming you are using at least one swap partition of 2 GB, or even if it's only a single gig, writing an appropriate value to image_size should make your resume MUCH more responsive than it was before, maintaining at least /some/ of your cache. The trade-off will be somewhat longer suspend and resume times, but at least here, I've found it very much worth it. What's great is that this hint is generic enough it should apply to pretty much anyone using suspend to disk, at least on Linux, regardless of what package manager they are using, or even what distribution. IOW, those running Red Hat or Fedora or SuSE or Ubuntu or even Linspire/Freespire, as long as they are using a relatively recent kernel with suspend to disk compiled in, should be able to make use of this. =8^) > the one interesting function that i'd like to test is the parallel > compilation feature, which i happened to find by chance in the forum. a > patch that allows portage to compile more packages at the same time if > the second package compiled does not trigger an installation of the > first one. for example i could compile gimp and knetworkmanager at the > same time if i had a good processor. I do this all the time, but "manually". That is, I routinely have 2-4, sometimes more (I've had up to 11, more than that I couldn't keep ahead of ensuring I was free of dependencies and doing the etc-updates faster than the things were getting compiled) windows open, compiling different things at the same time. That's especially true when KDE comes out with an update, and I have 90-some packages to update just from it, all coming out the same day. When I get my dual dual-cores, I expect it'll be even more so, altho practically speaking, I'm more likely to just set up two compiles at once and then go do something else (like checking the lists =8^) with the rest of my CPU time. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
