[gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560710200235p3cfe1396u7e9057fa6a427f84@××××××××××.com, 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

-- 
gentoo-amd64@g.o mailing list