| Message ID | 20220527000610.648627-1-zach@aquabyte.ai |
|---|---|
| State | New |
| Headers | show |
| Series | ccache.bbclass: document CCACHE_MAXSIZE variable | expand |
On Thu, May 26, 2022 at 5:06 PM Zach Welch <zach@mandolincreek.net> wrote: > > Setting this avoids premature cache object eviction during large builds. > > Signed-off-by: Zachary T Welch <zach@aquabyte.ai> > --- > meta/classes/ccache.bbclass | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass > index 4532894c57..913304ab35 100644 > --- a/meta/classes/ccache.bbclass > +++ b/meta/classes/ccache.bbclass > @@ -12,7 +12,12 @@ > # Set CCACHE_TOP_DIR to a shared dir > # CCACHE_TOP_DIR = /path/to/shared_ccache/ > # > -# - TO debug ccahe > +# - Adjust the ccache size limit to avoid overflow during large builds: > +# export CCACHE_MAXSIZE = "100G" > +# To find a reasonable limit, set this limit to 0 (no limit), then > +# observe how large the ccache directory grows. The default (ie 5GB) would seem safer for most users. Apart from some potential loss in performance, there's no downside to reaching the limit (i.e. there's no "overflow" as you describe it) and 5GB of compressed object code is already quite a lot. Growing much beyond that risks just filling the cache up with old stuff that's never going to be reused anyway. What kind of "large builds" are you seeing issues with? > +# - To debug ccache:> # export CCACHE_DEBUG = "1" > # export CCACHE_LOGFILE = "${CCACHE_DIR}/logfile.log" > # And also set PARALLEL_MAKE = "-j 1" to get make the log in order > -- > 2.25.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#166197): https://lists.openembedded.org/g/openembedded-core/message/166197 > Mute This Topic: https://lists.openembedded.org/mt/91366715/3619030 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [armccurdy@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 5/26/22 18:53, Andre McCurdy wrote: > On Thu, May 26, 2022 at 5:06 PM Zach Welch <zach@mandolincreek.net> wrote: >> >> Setting this avoids premature cache object eviction during large builds. ... > The default (ie 5GB) would seem safer for most users. Apart from some > potential loss in performance, there's no downside to reaching the > limit (i.e. there's no "overflow" as you describe it) and 5GB of > compressed object code is already quite a lot. Growing much beyond > that risks just filling the cache up with old stuff that's never going > to be reused anyway. > > What kind of "large builds" are you seeing issues with? For some reason, I had it in my head that the CCACHE_MAXSIZE limit was being applied to the CCACHE_TOP_DIR. Obviously, that's not the case; it applies to each individual per-arch/per-recipe cache. I ran a clean build, removed the tmp and sstate dirs, and built again; it looks like the default limit will be fine in most situations. Please drop this patch; sorry for the noise. Thanks, Zach
diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass index 4532894c57..913304ab35 100644 --- a/meta/classes/ccache.bbclass +++ b/meta/classes/ccache.bbclass @@ -12,7 +12,12 @@ # Set CCACHE_TOP_DIR to a shared dir # CCACHE_TOP_DIR = /path/to/shared_ccache/ # -# - TO debug ccahe +# - Adjust the ccache size limit to avoid overflow during large builds: +# export CCACHE_MAXSIZE = "100G" +# To find a reasonable limit, set this limit to 0 (no limit), then +# observe how large the ccache directory grows. +# +# - To debug ccache: # export CCACHE_DEBUG = "1" # export CCACHE_LOGFILE = "${CCACHE_DIR}/logfile.log" # And also set PARALLEL_MAKE = "-j 1" to get make the log in order
Setting this avoids premature cache object eviction during large builds. Signed-off-by: Zachary T Welch <zach@aquabyte.ai> --- meta/classes/ccache.bbclass | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)