| 1 |
On Thursday 07 March 2002 23:22, Jonathan Rippy wrote: |
| 2 |
> Sounds like it could really help out for those with slower |
| 3 |
> machines? |
| 4 |
> |
| 5 |
> Thought this might be interesting to everyone... |
| 6 |
|
| 7 |
hey indeed, thx for the hint! :) imho this looks like a really |
| 8 |
nice solution for most gentoo users. it's the classical approach |
| 9 |
of exchanging memory for performance (but in a new way :) |
| 10 |
|
| 11 |
due to this tools' capability to put the cache on a nfs drive |
| 12 |
it's suitable not only for fast/new but also for slow/old |
| 13 |
systems and especially for old notebooks (where buying another |
| 14 |
hd might not be "worth" the speedup or hd throughput is |
| 15 |
generally low anyway). for gentoo on old, space-limited systems |
| 16 |
and supposed there isn't any nfs available one might consider to |
| 17 |
delete seldom rebuilt packages from the cache to find a balance |
| 18 |
between "hd-space-waisting" and a faster remerge process. |
| 19 |
the real-world benefit of a compilercache for such systems |
| 20 |
probably depends a lot on how smart the cache-handling mechanism |
| 21 |
is in caching only often-used packages. thus it's probably worth |
| 22 |
to refrain from implementing a customized |
| 23 |
compilercache-like-tool but invest the time saved in developing |
| 24 |
a smart, customized cache-handling algorithm for the mentioned |
| 25 |
compilercache. |
| 26 |
|
| 27 |
things that might be interesting to discuss for cutting |
| 28 |
down compile-time or generally improving the (r)emerge process: |
| 29 |
|
| 30 |
- compilercache |
| 31 |
- cross-compilation option (compile on a fast system, rsync |
| 32 |
afterwards) |
| 33 |
- mosix (let a fast cpu compile, the slow machine only cares for |
| 34 |
the cached things etc.) |
| 35 |
- emerge --world rebuild (thus one could rsync everything to |
| 36 |
another box and rebuild the whole stuff there -> would still |
| 37 |
take a lot of time but be much more convenient than selecting |
| 38 |
and emerging the packages manually) |
| 39 |
- global (perhaps dynamic) option to set the priority/nice |
| 40 |
factor of gcc, wget/prozilla, portage and its children (would be |
| 41 |
suitable both for speeding it up and slowing it down -> gcc |
| 42 |
eating up all cpu power on a "live" server is not so cool) (-> |
| 43 |
or does there already exist such an option and i just have not |
| 44 |
noticed it?) |
| 45 |
- ?? |
| 46 |
|
| 47 |
and of course the combinations of these features |
| 48 |
|
| 49 |
regards |
| 50 |
|
| 51 |
dan |
| 52 |
|
| 53 |
-- |
| 54 |
...::: Daniel Mettler | http://www.numlock.ch :::.... |
Archives