1 |
2008/2/13, Duncan <1i5t5.duncan@×××.net>: |
2 |
> |
3 |
> Volker Armin Hemmann <volker.armin.hemmann@××××××××××××.de> posted |
4 |
> 200802131346.26316.volker.armin.hemmann@××××××××××××.de, excerpted below, |
5 |
> on Wed, 13 Feb 2008 13:46:26 +0100: |
6 |
> |
7 |
> > On Mittwoch, 13. Februar 2008, Duncan wrote: |
8 |
> >>>removed lots of irrelevant 'my hardware is so cool' stuff'. |
9 |
> > |
10 |
> > You forget some (little) things. Not everything can be swapped out. Swap |
11 |
> > is extremly slow AND it is much worse to swapout/swapin programm code |
12 |
> > that should be run, instead of fetching some files from disk while the |
13 |
> > programm runs. |
14 |
> |
15 |
> It's not always much worse, because as I explained, in my case, swap is 4- |
16 |
> way striped while most of the main system is only two-way striped. Thus, |
17 |
> that "irrelevant" stuff is relevant after all, because it alters the |
18 |
> conditions of the case in debate, because swap reads in at ~2x the speed |
19 |
> of most data read off disk including apps (which is itself ~2x what a |
20 |
> single-disk system might reasonably expect). |
21 |
> |
22 |
> I've a feeling not appreciating this, not appreciating that your "test" |
23 |
> case example of compiling with 2 gigs RAM vs only 1 has little to do with |
24 |
> what might occur with PORTAGE_TMPDIR on tmpfs vs on disk, and not |
25 |
> appreciating the point RF and I are both trying to make, is due to the |
26 |
> same logic flaw. |
27 |
|
28 |
|
29 |
well, for now, the fact for me are: |
30 |
1. no ram upgrade is good -> notebook ram costs much more than desktop one |
31 |
and the notebook itself has a limit |
32 |
2. small packages, that have much update during the single days of the week |
33 |
(i do sync once a day) get compiled at least 2-3 times faster than normal |
34 |
compilation into disk space |
35 |
3. big packages that usually compile in 30-40 mins now compile in about |
36 |
10minutes or so faster. to see how it feels to use tmpfs for compilation i |
37 |
have to upgrade kde. usually kde3 would build into 2 days of about 13 hours |
38 |
compilation time each. i'll have to see how fast would kde4 build. |
39 |
4. the sync now takes less than 2mins while normally it would take about |
40 |
10mins. |
41 |
i'll try out duncan's speedups for shm and but for the dev one i don't use |
42 |
baselayout 2 and i'm still with the 1st version, since i don't feel like |
43 |
upgrading to it yet. but i'd like to know some more about what are the |
44 |
improvements of the second version. |
45 |
5. as for the raid stuff i cannot do it since i've only got one disk. i'll |
46 |
try to see what happens with swap set to 100. |
47 |
6. if i use some other programs while compiling into tmpfs bigones i need to |
48 |
nice the process or i'll get some misbehaviour from the other programs. |
49 |
|
50 |
-- |
51 |
dott. ing. beso |