Re: [PATCH 0/2] Support for ccache

[Jan Kiszka <jan.kiszka@siemens.com>]

On 15.09.21 18:43, Henning Schild wrote:
> This looks like a very good addition to the sstate feature that has
> been brewing in our basement. The combination would be really cool.
> 
> With sstate we are already seeing drastic speedups because tasks get
> skipped over. But if a long compile task can not be taken from the
> cache, this guy could come in as just the helper we needed here.
> 
> We will look into combining the two and see when our in-house stuff is
> ready for sharing.
> 
> Our biggest issue still is "eviction". We decided to solve that with
> cron and wipe the whole cache every night. For sstate that is important
> because if debootstrap rootfss (something we cache) get too old, they
> would need "apt-get update/upgrade" ... so we only cache for so long.
> 
> Another reason for eviction might not just be age but space. How to
> make sure that ccache does not grow forever? Instructions on how to
> evict are missing in the documentation. Or is it somehow self
> regulating?

It's self-regulating, and you can set an upper size limit in
~/.ccache/ccache.conf. I'm running it locally for ages without observing
issues.

> 
> The next question is whether it is thread-safe, meaning many instances
> of isar/bitbake can use it at the same time. Possibly from multiple
> machines sharing that cache folder ...

It is by nature as it has to support make -j as well.

ccache is a rather solid, actually old technology. When we use it in
lock-step with the compiler shipped by the same debian release, we are
on a safe ground. If that qualifies for default-on, I don't know, but at
least "recommend-on".

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux