| 1 |
Neil Bothwick wrote: |
| 2 |
> On Thu, 06 Sep 2012 04:15:23 -0500, Dale wrote: |
| 3 |
> |
| 4 |
>>> You missed the point. One of the first thing emerge will do is to |
| 5 |
>>> uncompress the package. At this time, all the files are cached in RAM. |
| 6 |
>>> Hence, everything needed for the build/compilation will come from the |
| 7 |
>>> cache like it would do with tmpfs. |
| 8 |
>>> |
| 9 |
>> You miss this point not me. I *cleared* that cache. From kernel.org: |
| 10 |
> Sorry Dale, but you are missing the point. You cleared the cache before |
| 11 |
> running emerge, then ran emerge. The first thing emerge did was unpack |
| 12 |
> the tarball and populate the disk cache. All clearing the disk cache did |
| 13 |
> was make sure there was plenty of space to cache the new data, thus |
| 14 |
> speeding up the process. |
| 15 |
> |
| 16 |
> |
| 17 |
|
| 18 |
Then explain to me why it was at times slower while on tmpfs? Trust me, |
| 19 |
I ran this test many times and in different orders and it did NOT make |
| 20 |
much if any difference. |
| 21 |
|
| 22 |
I might add, the cache on the drive I was using is nowhere near large |
| 23 |
enough to cache the tarball for the package. Heck, the cache on my |
| 24 |
current system drive is only 8Mbs according to hdparm. That is not much |
| 25 |
since I tested using much larger packages. You can't cache files larger |
| 26 |
than the cache. |
| 27 |
|
| 28 |
Do I need to run a test, reboot, run the test again to show this is not |
| 29 |
making much if any difference? I mean, really? o_O |
| 30 |
|
| 31 |
Dale |
| 32 |
|
| 33 |
:-) :-) |
| 34 |
|
| 35 |
-- |
| 36 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |
Archives