Nicolas Sebrecht wrote:
> The 05/09/12, Dale wrote:
>> Michael Mol wrote:
>>> On Wed, Sep 5, 2012 at 11:17 AM, Neil Bothwick <n...@digimed.co.uk> wrote:
>>>> On Wed, 05 Sep 2012 07:52:45 -0500, Dale wrote:
>>>>
>>>>>>> I might also add, I see no speed improvements in putting portages
>>>>>>> work directory on tmpfs.  I have tested this a few times and the
>>>>>>> difference in compile times is just not there.
>>>>>> Probably because with 16GB everything stays cached anyway.
>>>>> I cleared the cache between the compiles.  This is the command I use:
>>>>>
>>>>> echo 3 > /proc/sys/vm/drop_caches
>>>> But you are still using the RAM as disk cache during the emerge, the data
>>>> doesn't stay around long enough to need to get written to disk with so
>>>> much RAM for cache.
>>> Indeed. Try setting the mount to write-through to see the difference.
>>>
>>>
>> When I run that command, it clears all the cache.  It is the same as if
>> I rebooted.  Certainly you are not thinking that cache survives a reboot?
> You missed the point. One of the first thing emerge will do is to
> uncompress the package. At this time, all the files are cached in RAM.
> Hence, everything needed for the build/compilation will come from the
> cache like it would do with tmpfs.
>

You miss this point not me.  I *cleared* that cache.  From kernel.org:

drop_caches

Writing to this will cause the kernel to drop clean caches, dentries and
inodes from memory, causing that memory to become free.

To free pagecache:
        echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
        echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
        echo 3 > /proc/sys/vm/drop_caches

I can confirm this is done with free, top or htop.  See my reply to Neil for 
more on this.

Dale

:-)  :-)  

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!


Reply via email to