Re: [gentoo-amd64] Re: tmpfs help

[Mateusz Mierzwinski]

Beso pisze:
>
>
> 2008/2/13, Duncan <1i5t5.duncan@×××.net <mailto:1i5t5.duncan@×××.net>>:
>
>     Volker Armin Hemmann <volker.armin.hemmann@××××××××××××.de
>     <mailto:volker.armin.hemmann@××××××××××××.de>> posted
>     200802131346.26316.volker.armin.hemmann@××××××××××××.de
>     <mailto:200802131346.26316.volker.armin.hemmann@××××××××××××.de>,
>     excerpted below,
>     on  Wed, 13 Feb 2008 13:46:26 +0100:
>
>     > On Mittwoch, 13. Februar 2008, Duncan wrote:
>     >>>removed lots of irrelevant 'my hardware is so cool' stuff'.
>     >
>     > You forget some (little) things. Not everything can be swapped
>     out. Swap
>     > is extremly slow AND it is much worse to swapout/swapin programm
>     code
>     > that should be run, instead of fetching some files from disk
>     while the
>     > programm runs.
>
>     It's not always much worse, because as I explained, in my case,
>     swap is 4-
>     way striped while most of the main system is only two-way
>     striped.  Thus,
>     that "irrelevant" stuff is relevant after all, because it alters the
>     conditions of the case in debate, because swap reads in at ~2x the
>     speed
>     of most data read off disk including apps (which is itself ~2x what a
>     single-disk system might reasonably expect).
>
>     I've a feeling not appreciating this, not appreciating that your
>     "test"
>     case example of compiling with 2 gigs RAM vs only 1 has little to
>     do with
>     what might occur with PORTAGE_TMPDIR on tmpfs vs on disk, and not
>     appreciating the point RF and I are both trying to make, is due to the
>     same logic flaw.
>
>
> well, for now, the fact for me are:
> 1. no ram upgrade is good -> notebook ram costs much more than desktop
> one and the notebook itself has a limit
> 2. small packages, that have much update during the single days of the
> week (i do sync once a day) get compiled at least 2-3 times faster
> than normal compilation into disk space
> 3. big packages that usually compile in 30-40 mins now compile in
> about 10minutes or so faster. to see how it feels to use tmpfs for
> compilation i have to upgrade kde. usually kde3 would build into 2
> days of about 13 hours compilation time each. i'll have to see how
> fast would kde4 build.
> 4. the sync now takes less than 2mins while normally it would take
> about 10mins.
> i'll try out duncan's speedups for shm and but for the dev one i don't
> use baselayout 2 and i'm still with the 1st version, since i don't
> feel like upgrading to it yet. but i'd like to know some more about
> what are the improvements of the second version.
> 5. as for the raid stuff i cannot do it since i've only got one disk.
> i'll try to see what happens with swap set to 100.
> 6. if i use some other programs while compiling into tmpfs bigones i
> need to nice the process or i'll get some misbehaviour from the other
> programs.
>
> --
> dott. ing. beso
yeah! Notebooks limit's... My notebook have EM64T extension so it's 36 
bit physical and 48 bit virtual address space for memory mappings - that 
means I could insert more than 2 GB of memory ;). My notebook is 
designed for 4GB.. is this not much? :> Half of my current linux 
filesystem in memory (including /etc and /usr recursively) :D:D:D:D. 
Sorry, but those limits are sick for normal usage of normal citizen 
:D:D:D. I think about, what You said about memory for laptops... I have 
DDR2 memory and it cost's same as normal DDR2 memory for standard PC - 
thats how it works in poland - just You need to find right shop ;).

Greetings
Mateusz M.
-- 
gentoo-amd64@l.g.o mailing list