Beso pisze:
>
>
> 2008/2/13, Duncan <1i5t5.duncan@... <mailto:1i5t5.duncan@...>>:
>
>     Volker Armin Hemmann <volker.armin.hemmann@...
>     <mailto:volker.armin.hemmann@...>> posted
>     200802131346.26316.volker.armin.hemmann@...
>     <mailto:200802131346.26316.volker.armin.hemmann@...>,
>     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@g.o mailing list