| 1 |
Neil Bothwick wrote: |
| 2 |
> On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote: |
| 3 |
> |
| 4 |
>> I don't think that is correct. I am clearing the files in ram. That's |
| 5 |
>> the point of drop_caches is to clear the kernels cache files. See post |
| 6 |
>> to Nicolas Sebrecht a bit ago. |
| 7 |
> Take a step back Dale and read the posts again. This is not about the |
| 8 |
> state of the cache at the start of the emerge but during it. You may |
| 9 |
> clear the cache before starting, but that doesn't stop is filling up |
| 10 |
> again as soon as the emerge reaches src_unpack(). |
| 11 |
> |
| 12 |
> This has nothing to do with caching the data from the previous emerge |
| 13 |
> run, it is all from the currently running emerge. You may think you are |
| 14 |
> unpacking the tarball to disk and then loading those files into the |
| 15 |
> compiler, but you are only using the copies that are cached when you |
| 16 |
> unpack. |
| 17 |
> |
| 18 |
> |
| 19 |
|
| 20 |
|
| 21 |
Then take a look at it this way. If I emerge seamonkey with portage's |
| 22 |
work directory on disk and it takes 12 minutes, the first time. Then I |
| 23 |
clear the caches and emerge seamonkey again while portage's work |
| 24 |
directory is on tmpfs and it is 12 minutes. Then repeat that process a |
| 25 |
few times more. If the outcome of all those emerges is 12 minutes, |
| 26 |
regardless of the order, then putting portages work directory on tmpfs |
| 27 |
makes no difference at all in that case. The emerge times are exactly |
| 28 |
the same regardless of emerge using cache or not or portage's work |
| 29 |
directory being on tmpfs or not. I don't care if emerge uses cache |
| 30 |
DURING the emerge process because it is always enabled in both tests. |
| 31 |
The point is whether portage's work directory is on tmpfs or not makes |
| 32 |
emerges faster. |
| 33 |
|
| 34 |
The thing about what you are saying is that I ran those tests with the |
| 35 |
files in memory. What I am saying is this, that is not the case. I am |
| 36 |
clearing that memory with the drop_cache command between each test. You |
| 37 |
claim that cache is affecting the timing but I am clearing the very same |
| 38 |
cache the same as a reboot would. The emerge times whether portage's |
| 39 |
work directory is on tmpfs or not didn't change enough to make a |
| 40 |
difference. That is what I am saying the tests resulted in. It was not |
| 41 |
what I expected but it is what I got. It is also what others got as well. |
| 42 |
|
| 43 |
I provided a link to the information that should be as clear as it |
| 44 |
gets. Can you provide a link that shows that the command does not clear |
| 45 |
the kernel cache? I'm going by what I linked to on kernel.org. Since |
| 46 |
they are the ones that make the kernels, I think they should know what |
| 47 |
it is and what it does. |
| 48 |
|
| 49 |
Here is some more links with the same info really: |
| 50 |
|
| 51 |
http://linux-mm.org/Drop_Caches |
| 52 |
|
| 53 |
http://www.linuxinsight.com/proc_sys_vm_drop_caches.html |
| 54 |
|
| 55 |
http://bjdean.id.au/wiki/LinuxMemoryManagement |
| 56 |
|
| 57 |
Those are all the first links in a google search for "drop_caches |
| 58 |
kernel". See if you can find anything that says otherwise. |
| 59 |
|
| 60 |
Dale |
| 61 |
|
| 62 |
:-) :-) |
| 63 |
|
| 64 |
-- |
| 65 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |
Archives