Searched +hist:16 +hist:f89098 (Results 1 - 1 of 1) sorted by relevance
| /linux-master/ | ||
| H A D | Makefile | diff aba09154 Wed May 01 16:55:25 MDT 2024 Nathan Chancellor <nathan@kernel.org> kbuild: Remove support for Clang's ThinLTO caching There is an issue in clang's ThinLTO caching (enabled for the kernel via '--thinlto-cache-dir') with .incbin, which the kernel occasionally uses to include data within the kernel, such as the .config file for /proc/config.gz. For example, when changing the .config and rebuilding vmlinux, the copy of .config in vmlinux does not match the copy of .config in the build folder: $ echo 'CONFIG_LTO_NONE=n CONFIG_LTO_CLANG_THIN=y CONFIG_IKCONFIG=y CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config CONFIG_HEADERS_INSTALL=y $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y $ scripts/config -d HEADERS_INSTALL $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux ... UPD kernel/config_data GZIP kernel/config_data.gz CC kernel/configs.o ... LD vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config # CONFIG_HEADERS_INSTALL is not set $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y Without '--thinlto-cache-dir' or when using full LTO, this issue does not occur. Benchmarking incremental builds on a few different machines with and without the cache shows a 20% increase in incremental build time without the cache when measured by touching init/main.c and running 'make all'. ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s] Range (min … max): 56.109 s … 56.594 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s] Range (min … max): 67.059 s … 68.556 s 10 runs Summary With ThinLTO cache ran 1.20 ± 0.01 times faster than Without ThinLTO cache ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s] Range (min … max): 85.447 s … 86.244 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s] Range (min … max): 103.286 s … 104.124 s 10 runs Summary With ThinLTO cache ran 1.21 ± 0.00 times faster than Without ThinLTO cache While it is unfortunate to take this performance improvement off the table, correctness is more important. If/when this is fixed in LLVM, it can potentially be brought back in a conditional manner. Alternatively, a developer can just disable LTO if doing incremental compiles quickly is important, as a full compile cycle can still take over a minute even with the cache and it is unlikely that LTO will result in functional differences for a kernel change. Cc: stable@vger.kernel.org Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Reported-by: Yifan Hong <elsk@google.com> Closes: https://github.com/ClangBuiltLinux/linux/issues/2021 Reported-by: Masami Hiramatsu <mhiramat@kernel.org> Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 604a57ba Fri Apr 05 16:56:03 MDT 2024 Rob Herring <robh@kernel.org> dt-bindings: kbuild: Add separate target/dependency for processed-schema.json Running dtbs_check and dt_compatible_check targets really only depend on processed-schema.json, but the dependency is 'dt_binding_check'. That was sort worked around with the CHECK_DT_BINDING variable in order to skip some of the work that 'dt_binding_check' does. It still runs the full checks of the schemas which is not necessary and adds 10s of seconds to the build time. That's significant when checking only a few DTBs and with recent changes that have improved the validation time by 6-7x. Add a new target, dt_binding_schema, which just builds processed-schema.json and can be used as the dependency for other targets. The scripts_dtc dependency isn't needed either as the examples aren't built for it. Signed-off-by: Rob Herring <robh@kernel.org> Tested-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff ecab4115 Fri Feb 16 17:26:37 MST 2024 Miguel Ojeda <ojeda@kernel.org> kbuild: mark `rustc` (and others) invocations as recursive `rustc` (like Cargo) may take advantage of the jobserver at any time (e.g. for backend parallelism, or eventually frontend too). In the kernel, we call `rustc` with `-Ccodegen-units=1` (and `-Zthreads` is 1 so far), so we do not expect parallelism. However, in the upcoming Rust 1.76.0, a warning is emitted by `rustc` [1] when it cannot connect to the jobserver it was passed (in many cases, but not all: compiling and `--print sysroot` do, but `--version` does not). And given GNU Make always passes the jobserver in the environment variable (even when a line is deemed non-recursive), `rustc` will end up complaining about it (in particular in Make 4.3 where there is only the simple pipe jobserver style). One solution is to remove the jobserver from `MAKEFLAGS`. However, we can mark the lines with calls to `rustc` (and Cargo) as recursive, which looks simpler. This is being documented as a recommendation in `rustc` [2] and allows us to be ready for the time we may use parallelism inside `rustc` (potentially now, if a user passes `-Zthreads`). Thus do so. Similarly, do the same for `rustdoc` and `cargo` calls. Finally, there is one case that the solution does not cover, which is the `$(shell ...)` call we have. Thus, for that one, set an empty `MAKEFLAGS` environment variable. Link: https://github.com/rust-lang/rust/issues/120515 [1] Acked-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://github.com/rust-lang/rust/pull/121564 [2] Link: https://lore.kernel.org/r/20240217002638.57373-1-ojeda@kernel.org [ Reworded to add link to PR documenting the recommendation. ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> diff d206a76d Sun Feb 25 16:46:06 MST 2024 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.8-rc6 diff ceb6a6f0 Sun Dec 17 16:19:28 MST 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.7-rc6 diff 98b1cc82 Sun Nov 19 16:02:14 MST 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.7-rc2 diff c40e60f0 Tue Jul 04 16:19:51 MDT 2023 Borislav Petkov (AMD) <bp@alien8.de> kbuild: Enable -Wenum-conversion by default This diagnostic checks whether there is a type mismatch when converting enums (assign an enum of type A to an enum of type B, for example) and it caught a legit issue recently. The reason it didn't show is because that warning is enabled only with -Wextra with GCC. Clang, however, enables it by default. GCC folks were considering enabling it by default but it was too noisy back then: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 Now that due to clang all those warnings have been fixed, enable it with GCC too. allmodconfig tests done with: x86, arm{,64}, powerpc{,64}, riscv crossbuilds. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 9418e686 Sat Jul 29 16:03:17 MDT 2023 Miguel Ojeda <ojeda@kernel.org> rust: enable `no_mangle_with_rust_abi` Clippy lint Introduced in Rust 1.69.0 [1], this lint prevents forgetting to set the C ABI when using `#[no_mangle]` (or thinking it is implied). For instance, it would have prevented the issue [2] fixed by commit c682e4c37d2b ("rust: kernel: Mark rust_fmt_argument as extern "C""). error: `#[no_mangle]` set on a function with the default (`Rust`) ABI --> rust/kernel/print.rs:21:1 | 21 | / unsafe fn rust_fmt_argument( 22 | | buf: *mut c_char, 23 | | end: *mut c_char, 24 | | ptr: *const c_void, 25 | | ) -> *mut c_char { | |________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#no_mangle_with_rust_abi = note: requested on the command line with `-D clippy::no-mangle-with-rust-abi` help: set an ABI | 21 | unsafe extern "C" fn rust_fmt_argument( | ++++++++++ help: or explicitly set the default | 21 | unsafe extern "Rust" fn rust_fmt_argument( | +++++++++++++ Thus enable it. In rare cases, we may need to use the Rust ABI even with `#[no_mangle]` (e.g. one case, before 1.71.0, would have been the `__rust_*` functions). In those cases, we would need to `#[allow(...)]` the lint, since using `extern "Rust"` explicitly (as the compiler suggests) currently gets overwritten by `rustfmt` [3]. Link: https://github.com/rust-lang/rust-clippy/issues/10347 [1] Link: https://github.com/Rust-for-Linux/linux/pull/967 [2] Link: https://github.com/rust-lang/rustfmt/issues/5701 [3] Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Link: https://lore.kernel.org/r/20230729220317.416771-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> diff d824d2f9 Thu Jun 15 18:16:21 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: rust_is_available: remove -v option The -v option is passed when this script is invoked from Makefile, but not when invoked from Kconfig. As you can see in scripts/Kconfig.include, the 'success' macro suppresses stdout and stderr anyway, so this script does not need to be quiet. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230109061436.3146442-1-masahiroy@kernel.org [ Reworded prefix to match the others in the patch series. ] Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Link: https://lore.kernel.org/r/20230616001631.463536-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> diff 52a93d39 Sun Aug 06 16:07:51 MDT 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.5-rc5 |
Completed in 1242 milliseconds