Zfs: ./configure probes take ages

Created on 29 Mar 2019  路  4Comments  路  Source: openzfs/zfs

System information

Type | Version/Name
--- | ---
Distribution Name | Debian
Distribution Version | Buster Alpha 5
Linux Kernel | 4.19.0-4-powerpc64le
Architecture | POWER 9
ZFS Version | 0.7.12
SPL Version | 0.7.12

Describe the problem you're observing

./configure probes to the linux kernel take several (nearly 10) seconds per probe, thanks to all the make and shell that gets spawned. It would be far better, IMHO, to launch a single, parallelisable compilation (using, e.g., make -k) of all possible probes, and then deduce the results afterwards.

Describe how to reproduce the problem

Type ./configure, go take a shower and make some tea.

Building Feature

Most helpful comment

@nwf using make -k and running all the check in parallel is an interesting idea. It would be great if you could investigate this approach and determine if it's viable. No one more than myself would like to see this sped up.

All 4 comments

@nwf using make -k and running all the check in parallel is an interesting idea. It would be great if you could investigate this approach and determine if it's viable. No one more than myself would like to see this sped up.

Yes. It's funny how it configures for 15 minutes and then compiles in 15 seconds...

@behlendorf cool!

BTW are these checks there to check the ZFS code or the system that i am building at?

If it tests the ZFS code itself, then it can be done using some continuous integration system directly when pushed to git.

If it tests the build environment (eg. my laptop) i think these tests can be cached between builds as long as i do not upgrade my system, in which case i might just do make clean to run the checks again. So if only ZFS code changes, but my build environment stays the same, we might not need checking it again.

But i don't really know how this works, it's just idea.

@Harvie caching the results for a specific kernel is definitely possible. I left that as possible future work. But what you'd need to do it include some unique kernel identifier in the build results. That would allow you to know if you need to rerun a given check.

Was this page helpful?
0 / 5 - 0 ratings