[ccache] Stumbling blocks with ccache and embedded/encapsulated environments

Martin Pool mbp at sourcefrog.net
Thu Dec 2 18:12:17 MST 2010

On 3 December 2010 11:29, Justin Lebar <justin.lebar at gmail.com> wrote:
>>> Even on a ccache *hit* both copies of the .o file wind up occupying
>>> buffer cache space, because the ccached .o is read from disk [paging
>>> it in] in order to write the .o file to the build output directory.
>>> On a ccache miss the copy runs the other direction but you still wind
>>> up with both sets of pages in the buffer cache.
>> In the hit case I would have thought that the .o file you read would
>> still create less memory pressure than the working memory of running
>> the real compiler on that file?  Perhaps the difference is that the
>> kernel knows that when the compiler exits, its anonymous pages can be
>> thrown away, whereas it doesn't know which .o file it ought to retain.
>>  So perhaps madvise might help.  (Just speculating.)
> I'm curious about this.  I guess you'd madvise to tell the kernel that
> the .o you just wrote shouldn't be cached?  But presumably it should
> be, because you're going to link your program.
> Alternatively, you could madvise and tell the kernel not to cache the
> .o file from ccache's cache.  But if you re-compile, you want ccache's
> cache to be in memory.

I meant the latter.  It seems like the common case is that you're more
likely to link next than to recompile the same source.

I don't know if this would actually work.  It may be that madvise is
too weak to make a difference, or it may be it's so strong that it
causes potentially useful things to be thrown out too soon.  For that
matter there are vm tuning knobs too.  Perhaps this is getting too far
into futzing.  I'm not going to do it myself because I don't build
such huge trees at the moment.  But it's interesting to contemplate.


More information about the ccache mailing list