Use ccache for CI #977
Use ccache for CI #977
Conversation
|
LGTM |
|
@davidbeckingsale it looks like the issue is related to directory permissions for gitlab ci |
|
LGTM |
| if [[ ${sys_type} == *toss_3* ]]; then | ||
| cmake \ | ||
| -DENABLE_CCACHE=ON \ | ||
| -DCCACHE_DIR=/collab/usr/global/tools/ccache/toss_3_x86_64_ib/ccache-4.2/bin/ccache \ |
There was a problem hiding this comment.
Does ccache work well with a single location that may be targeted by several builds simultaneously? (Maybe it creates a unique subdir per configuration hash?)
Also, in the log I see:
CMake Warning:
Manually-specified variables were not used by the project:
CCACHE_DIR
Are we sure this is taken into account by BLT?
There was a problem hiding this comment.
Oops, that's the binary location, not the location of the data...
Then, where is the data stored? If it's in the working directory, then I'm afraid this won't help much. That's because the working directory changes with the runner hash, the job rank on the runner (0 to 7), and then we have no guarantee that the same target will be rebuilt there.
This is not a lost cause though.
There was a problem hiding this comment.
That's a typo in my BLT changes :D and we can change the location via a config file. I am trying to work out the best way to set up the config, I think we will need to it via env var.
|
We should probably chat about this. I don't have it easily accessible
right now, but it's entirely possible to make a safe shared access
location for ccache across machines and parallel builds. The worst I've
ever seen happen is the amount of cache misses increases if the hashing
setup and certain other things are messed up. Having it on NFS can cause
issues, but they basically always show up as a loss of potentially
improved performance rather than something nastier.
|
|
I went through and reminded myself of the usual options. We probably want to play with the sloppiness settings (especially the ctime and mtime sloppiness since files are going to have different times constantly) but for now just adding |
|
/tmp is local to each node right? The node used for CI will change constantly, except if we decide to always use the same for a given job. |
|
It’s usually a memory backed file system in LC. That’s ideal really, as long as we make sure the stuff gets cleaned out so we don’t oom the node.
On Mar 15, 2021, at 6:00 PM, Adrien Bernede ***@***.***> wrote:
/tmp is local to each node right? The node used for CI will change constantly, except if we decide to always use the same for a given job.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https://github.com/LLNL/RAJA/pull/977*issuecomment-799863867__;Iw!!G2kpM7uM-TzIFchu!jG0YzgNgF26p1BRWDXA-PjtDwFy58HNoRs_98x01TNWZ-n4avhVT4iRYSu4GIWeqxw$>, or unsubscribe<https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/AAFBFNKLZPPAA2Q7JDYTDWLTD2UTPANCNFSM4YTS4BHA__;!!G2kpM7uM-TzIFchu!jG0YzgNgF26p1BRWDXA-PjtDwFy58HNoRs_98x01TNWZ-n4avhVT4iRYSu7T-d4YyQ$>.
|
Summary