Gentoo Portage emerge TMPDIR extending zram btrfs volumes

You can probably see I was heading this way. This post follows a series, and you should read those posts again if you haven't done so recently. This blog post follows my journey through btrfs to gentoo to portage to tmpfs to zram back to btrfs again to finish a circle.

Discovering zram and replacing all tmpfs

I have just discovered zram^[2] :) woohoo... and what a thing that is!

I was so sold on tmpfs, that I used it for everything I possibly could. Since discovering zram, I am using tmpfs for nothing. All my tmpfs needs are met by zram much more efficiently.

gentoo emerge in tmpfs

One of my gentoo pain points has been the extremely (long and) resource intensive emerge for large packages. However, it is expected and many have come up with their own tricks to make this more efficient.

For me, this has been a gradual step-by-step approach, as I encountered these issues and discovered more about Gentoo.

I stated out with my portage configured as default -- compiling everything on the same disk/filesystem mount on my rotating (not ssd) disk. Any emerge affected everything else, which was too invasive to ignore.

I want emerge to run gently in the background, not affecting any foreground tasks.

using tmpfs

i find my ram usage doesn't go much over 512k. apart from some of my trusty older friends, most of my systems have ample ram left over. how do i make more efficient usage of extra ram?

ram is fast. disk is slow. move more operations from disk to ram, depending on how ram is spare.

all that glitters..??

"Never buy low serial numbers." Easy advice to give, but hard to follow. Witness the modern-day genius of pre-marketing: every time a neat new hi-tech gadget gets announced, a virtual army of unsuspecting consumers turns out to pay for the privilege of becoming beta-testers. Egging them on are "reviewers" (possibly hired shills), who write glowing reviews of the as-yet unmanufactured product in question. Occasionally, we are treated to videos of consumers camping out overnight in front of an electronics store for the privilege of being first in line to purchase a shiny new experimental gizmo that the manufacturer needs to get rid of before a greatly-improved version 2.0 is launched a few months later... http://distrowatch.com/weekly.php?issue=20111205#feature

I could haven't have written it any better than Robert Storey, as above.

i found an old .iso in my archives. wondering why i had it in the first place, i started exploring it... i am most impressed by WattOS R4. i couldn't believe how fast it boots, how efficient it's footprint is, and still functional. i have it installed now and think i am going to keep it.

i am using wattos4 as a browser appliance - extremely nimble and fast. who would have believed it from an ubuntu base! so, i plonked for it's latest iteration WattOS R6, and found it to be slightly worse than wattosr4.

i have reviewed antix before, but i can't recollect. i will have a look and update this post here.

android roadmap?

i'm not sure which way google are going, but they seem to want to turn the android into a desktop os, rather than a handheld os. google are doing to android, what microsoft did to windows.. make it bloatware & proprietary locking everyone out, till people give up and move to alternatives.

mtrr cleanup

having just done an upgrade, i went through the logs and found some mtrr #fail issues.

$ dmesg | grep -i mtrr
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
[    5.811624] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
[    5.811628] [drm] MTRR allocation failed.  Graphics performance may suffer.

$ cat /proc/mtrr
reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable
reg01: base=0x000000000 (    0MB), size= 4096MB, count=1: write-back
reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg03: base=0x0bf700000 ( 3063MB), size=    1MB, count=1: uncachable
reg04: base=0x0bf800000 ( 3064MB), size=    8MB, count=1: uncachable

the above doesn't seem to add up right. note that i have 4gb of memory on this machine.

debian testing 3.2.0-2-amd64 #1 SMP Fri Jun 1 17:49:08 UTC 2012 x86_64 GNU/Linux

i found many recommendations to enable_mtrr_cleanup, including this: http://forums.gentoo.org/viewtopic-t-857061-start-0-postdays-0-postorder-asc-highlight-.html. so i added the kernel bootoptions

enable_mtrr_cleanup mtrr_spare_reg_nr=1

to the grub commandline, and here is the result.

$ dmesg | grep -i mtrr
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
[    0.000000] original variable MTRRs
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000] New variable MTRRs

$ cat /proc/mtrr
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0bf700000 ( 3063MB), size=    1MB, count=1: uncachable
reg03: base=0x0bf800000 ( 3064MB), size=    8MB, count=1: uncachable
reg04: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg05: base=0x0d0000000 ( 3328MB), size=  256MB, count=1: write-combining

now this look much better! i'm keeping this kernel bootoption. have a go yourself, and post your (before/after) results below.

update: i should use mtrr_spare_reg_nr=0, as the first reg is 00.