On 3 December 2010 11:29, Justin Lebar <justin.le...@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. -- Martin _______________________________________________ ccache mailing list firstname.lastname@example.org https://lists.samba.org/mailman/listinfo/ccache