Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 12 Aug 2008 08:23:06 +0000:
> 2008/8/12 Morgan Wesström <[EMAIL PROTECTED]> > >> Duncan wrote: >> >>> Now, if you /really/ want to make a difference in portage's speed, >>> consider pointing PORTAGE_TMPDIR at a tmpfs. >>> >> This advice caught my attention since I moved my tmp space to Reiserfs >> for performance reasons. My knowledge of tmpfs is limited but I think >> it is a filesystem that uses RAM and can grow and shrink dynamically, >> right? If I follow this advice, what happens when I compile something >> like Open Office which allocates 3-4GB in /var/tmp during compilation >> and I only have 2GB physical RAM in the computer? >> > you'll use swap partition. but you'll not allocate all that ram space > with openoffice. i've tried to compile it twice. first time it was on > disk and it took almost 14 hours of compilation. the second time was on > tmpfs with 3.8gb and a 6gb swap file and it took less than 8 hours and > i've never filled the swap partition. to put at maximum use this method > with low ram then don't start xorg and graphical terminals but only the > base vt and compile from there. this will save you quite some ram space. > you'll also find that the -j option in your make.conf could be increased > much when going with tmpfs. for example i've passed from -j5 in hd use > to -j9 in tmpfs and i still have a very good and usable graphical > system. with the old single core pc i was using -j2 in hd and -j5 on > tmpfs. this dramattically decreases compilation time. This well illustrates the speed-up of PORTAGE_TMPDIR on tmpfs. Now, I don't use -j -l MAKEOPTS to control load so much as to control memory usage. I can have a load in the hundreds and it doesn't matter that much, particularly with per-user scheduling turned on in the kernel, but of course memory can still be an issue if compiling into tmpfs and too many jobs get going. I'll second that tmpfs is swappable as well. That makes it great for compiling (as long as you have enough swap), because even when real memory isn't enough to hold it all and it swaps some of it, many of the shortest lived files never hit disk at all, making it MUCH faster, and, as Beso points out, MUCH more responsive on other things as well, even with more jobs going, because of the nature of disk I/O. Morgan also asks (down-thread) about compiling OOo with 2 gig RAM and 1 gig swap. Yes, that'll be problematic. One thing you could do would be to shrink or kill entirely the partition you are using for /tmp and/or /var/tmp (or wherever else you are currently compiling OOo into that obviously has that much space) and turn it into more swap. Another alternative is to setup swap files. With 3 gigs total mem+swap, if you don't want any more swap under normal conditions, this would allow you to create it temporarily out of normal filesystem space, only for merging big stuff like OOo. It won't be quite as fast that way, but it should still be way faster than compiling it to PORTAGE_TMPDIR on disk. A third alternative would be to point PORTAGE_TMPDIR at tmpfs for normal merges, and just point it back at disk temporarily when emerging OOo. Of course, that would be slow again, but no slower than now, and you'd still have the speedup when merging most stuff. Personally, I'd recommend the first, recovering disk space currently used for /tmp or /var/tmp, and turning it into swap. > @duncan: do you remember that some time ago you were speaking about > posting the scripts to compile the kernel with the make.conf > optimizations, but you haven't posted them any more. do you still use > them?! I remember, and yes, I'm still using them. I had to fix something recently, when debianutils changed its kernel install scripts, but I still use them. I still have to get it on the webspace, but thanks for reminding me. -- 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
