Am 13.02.24 um 18:52 schrieb Julian Sikorski:
Am 13.02.24 um 16:16 schrieb Gary Buhrmaster:
On Tue, Feb 13, 2024 at 9:52 AM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote:
Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a):
Could this be the reason for ccache not working?
I wonder whether it is Mock problem, Ccache issue or problem in
packaging? Does the ccache speadup the build when you
run it with plain rpmbuild and ccache on host?
I have lost track of the details (and the
version of ccache when the issue was
addressed/patched), but ccache at one
time included SOURCE_DATE_EPOCH
in the default hash, resulting in no
cache hits.
This appears to have been fixed in ccache-4.2. F36, obsolete as it is,
shipped with 4.5.1.
Having said that, with current kernel there is this line in the log:
+ perl -p -i -e
's/^CONFIG_BUILD_SALT.*/CONFIG_BUILD_SALT="6.7.4-200.lacie03.fc39.x86_64"/' .config
This would change every build.
Best regards,
Julian
I had to bisect a kernel regression once again so I revisited this. I
have modified my mock with PR showing ccache stats [1].
Interestingly enough, rebuilding the exact same srpm does result in a
significant speedup and almost 100% cache hits. Build took ~12 minutes
(as opposed to ~25 when building without cache) and cache stats looks as
follows:
DEBUG util.py:463: Cacheable calls: 21570 / 21954 (98.25%)
DEBUG util.py:463: Hits: 21554 / 21570 (99.93%)
DEBUG util.py:463: Direct: 21458 / 21554 (99.55%)
DEBUG util.py:463: Preprocessed: 96 / 21554 ( 0.45%)
DEBUG util.py:463: Misses: 16 / 21570 ( 0.07%)
DEBUG util.py:463: Uncacheable calls: 384 / 21954 ( 1.75%)
Next bisect step, couple hundred commits away (from fe46a7dd189e to
eaf0e7a3d271 in case this is relevant), is a completely different story.
Build took ~45 minutes and there are almost no cache hits:
DEBUG util.py:463: Cacheable calls: 21554 / 21938 (98.25%)
DEBUG util.py:463: Hits: 1421 / 21554 ( 6.59%)
DEBUG util.py:463: Direct: 1365 / 1421 (96.06%)
DEBUG util.py:463: Preprocessed: 56 / 1421 ( 3.94%)
DEBUG util.py:463: Misses: 20133 / 21554 (93.41%)
DEBUG util.py:463: Uncacheable calls: 384 / 21938 ( 1.75%)
Further down the bisect, despite differences from build to build getting
smaller, there is almost no difference. From 902861e34c40 to
e5eb28f6d1af, build took around ~45 minutes too, and almost no cache
hits were found either:
DEBUG util.py:463: Cacheable calls: 21571 / 21955 (98.25%)
DEBUG util.py:463: Hits: 1395 / 21571 ( 6.47%)
DEBUG util.py:463: Direct: 1373 / 1395 (98.42%)
DEBUG util.py:463: Preprocessed: 22 / 1395 ( 1.58%)
DEBUG util.py:463: Misses: 20176 / 21571 (93.53%)
DEBUG util.py:463: Uncacheable calls: 384 / 21955 ( 1.75%)
Can the cache files be inspected with something to see what is getting
cached?
Best regards,
Julian
[1] https://github.com/rpm-software-management/mock/pull/1299
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
