View previous topic :: View next topic |
Author |
Message |
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Mon Jan 17, 2022 1:59 pm Post subject: Testing fast kernel headers v2 @gentoo-sources-5.16.x: How 2 |
|
|
Currently looking for a convenient method to apply Ingo Molnar's Fast kernel headers to gentoo-sources.
Will update here for relevant finds, if any.
In the mean time, some may have some experience to share in this regard...
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here.
Last edited by CaptainBlood on Tue Feb 01, 2022 12:04 pm; edited 7 times in total |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Tue Jan 18, 2022 3:07 pm Post subject: |
|
|
Code: | temporary timing gcc-config -l
[1] x86_64-pc-linux-gnu-8.5.0
[2] x86_64-pc-linux-gnu-9.4.0
[3] x86_64-pc-linux-gnu-10.3.1
[4] x86_64-pc-linux-gnu-11.2.1 *
| results on Xeon E3-1200 v5/E3-1500 & 4 Gb ram & 5400 tpm harddisk:
CONFIG_TRIM_UNUSED_KSYM=Y
original
501 seconds
4141952 janv. 18 17:12 vmlinuz-5.16.1-gentoo-r8168
fast headers:
398 seconds
4430272 janv. 18 17:34 vmlinuz-5.16.1-gentoo-r81v2 Code: | diff .config /usr/src/linux-5.16.1-gentoo-r81v2/.config
3c3
< # Linux/x86 5.16.1-gentoo-r8168 Kernel Configuration
---
> # Linux/x86 5.16.1-gentoo-r81v2 Kernel Configuration
146a147
> CONFIG_FAST_HEADERS=y
669a671,672
> CONFIG_ARCH_SUPPORTS_PER_TASK=y
> CONFIG_ARCH_SUPPORTS_PER_TASK_0_OFFSET=y
695a699
> CONFIG_HAVE_OBJTOOL_KALLSYMS=y
753c757 | which might explain size increase.
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Tue Jan 18, 2022 7:34 pm Post subject: |
|
|
Are there any improvements in day to day performance of the kernel, or is it only in compile time?
My first impression is that this was a useful code cleanup effort with a side benefit that it compiles slightly faster (which I'm sure is nice for repeatedly building kernels, but less beneficial to the casual compiler). _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Wed Jan 19, 2022 8:16 am Post subject: |
|
|
pip,
Blocking issues here, as external modules such as vhba & r8168 don't compile, because of implicit declaration.
I"m currenly having a hard time finding a method to walk through involded nested original headers to retrieve patched bit(s) causing the issue.
Seems to me like a cleaning effort too.
Many .config files for # vmlinux-5.16.x here, regularly updated here. So it may be worthing in the long run, i.e. before it gets merged into kernel:
this is RH originated work, taken into account by google, which may indicate merging will eventually occur.
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Wed Jan 19, 2022 3:02 pm Post subject: |
|
|
vhba has been successfully patched,
r8168 seems more complicated.
Side note: CONFIG_FAST_HEADERS=n in .config supposedly allows to fall back to regular configuration.
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Thu Jan 20, 2022 1:13 am Post subject: |
|
|
Thanks. If nothing else it sounds like it isn't quite ready for general use. I haven't made the jump to 5 yet, but may do so before mid-year to whatever the newest long term support version is. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Thu Jan 20, 2022 2:31 am Post subject: |
|
|
As it was described on LWN when it was first reported, correct, it is not ready for general use yet. It should be viable for those configurations where it builds at all, and it offers notable improvements in compilation time. |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Mon Jan 24, 2022 2:14 pm Post subject: |
|
|
Code: | git clone --branch sched/headers git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git
git -C tip --no-pager diff 45b01cd5a6ffb26f6059ed4a6efdc80e51ff3845 4c707c1c0de83967079b4e385012fa5b00e2cd11 | tee ~/kernel-5.16-fast-headers-v2-branch-shed-headers.patch | patch -d /usr/src/linux-5.16.1-gentoo --dry-run -p1 -s | should
1) clone git directory. (+2h lasting process here)
2 extract a patch file to ~ and test it silently against a gentoo-sources directory. (should only output on error because of final -s)
Feel free to apply generated patch file, i.e. ~/kernel-5.16-fast-headers-v2-branch-shed-headers.patch here.activates Code: | [General setup]CONFIG_FAST_HEADERS=y | which will remain not visible until Code: | [General setup]CONFIG_COMPILE_TEST=y | which activation disables CONFIG_TRIM_UNUSED_KSYMS.
Thks 4 ur attention, interest & support.[/code] _________________ USE="-* ..." in /etc/portage/make.conf here.
Last edited by CaptainBlood on Mon Jan 24, 2022 3:07 pm; edited 2 times in total |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Mon Jan 24, 2022 2:40 pm Post subject: |
|
|
the review on the kernel ml highlighted that the "optimisation" went too far in quite a few places and some aspects of the macro's were needed to provide the flexibility (and thus in-lining a load of things isn't always the right option and probably only worked for Ingo's test cases.)
I would say its really too soon to be trying this _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 4124 Location: Bavaria
|
Posted: Mon Jan 24, 2022 2:53 pm Post subject: |
|
|
Naib wrote: | I would say its really too soon to be trying this |
I see it the same ... too soon for me ... but ... I like it very much when someone tries it and reports his experience here. It could be helpful in the future ... |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Mon Jan 24, 2022 3:04 pm Post subject: |
|
|
pietinger wrote: | I see it the same ... too soon for me ... but ... I like it very much if someone tries it and reports his experience here. It can be helpful in the future ... | Post #2 reports about kernel sizes and build time #.
Generated kernel works fine here.
vhba & r8168 external module packages both require patching.
Free free to ask for publication of any of them if required.
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Mon Jan 24, 2022 3:24 pm Post subject: |
|
|
Naib wrote: | the review on the kernel ml highlighted that the "optimisation" went too far in quite a few places and some aspects of the macro's were needed to provide the flexibility (and thus in-lining a load of things isn't always the right option and probably only worked for Ingo's test cases.) | Inlining excess may explain current unexpected kernel size increase.
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Mon Jan 24, 2022 7:17 pm Post subject: |
|
|
works fine on 5.16.1, removed from portage tree.
fails on 5.16.2
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Tue Jan 25, 2022 6:24 am Post subject: |
|
|
Naib wrote: | the review on the kernel ml highlighted that the "optimisation" went too far in quite a few places and some aspects of the macro's were needed to provide the flexibility (and thus in-lining a load of things isn't always the right option and probably only worked for Ingo's test cases.)
I would say its really too soon to be trying this | Hopefully Ingo got something out of it, otherwise that has to be a bit disheartening given the amount of time put into it. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3595
|
Posted: Thu Jan 27, 2022 1:03 pm Post subject: |
|
|
CaptainBlood wrote: | fails on 5.16.2 | Not anymore when applying: Code: | diff -Naur /usr/local/share/kernel/patches/fast-headers/kernel-5.16-fast-headers-v2-branch-sched-headers-0.patch /usr/local/share/kernel/patches/fast-headers/kernel-5.16-fast-headers-v2-branch-sched-headers-1.patch
--- /usr/local/share/kernel/patches/fast-headers/kernel-5.16-fast-headers-v2-branch-sched-headers-0.patch 2022-01-24 17:22:11.032204423 +0300
+++ /usr/local/share/kernel/patches/fast-headers/kernel-5.16-fast-headers-v2-branch-sched-headers-1.patch 2022-01-27 15:11:30.563226789 +0300
@@ -403467,7 +403467,7 @@
index 0dcfd265beed..24d9d72dd189 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
-@@ -14,1628 +14,10 @@
+@@ -14,1639 +14,10 @@
#ifndef _LINUX_PERF_EVENT_H
#define _LINUX_PERF_EVENT_H
@@ -404698,7 +404698,18 @@
- enum perf_bpf_event_type type,
- u16 flags);
-
--extern struct perf_guest_info_callbacks *perf_guest_cbs;
+-extern struct perf_guest_info_callbacks __rcu *perf_guest_cbs;
+-static inline struct perf_guest_info_callbacks *perf_get_guest_cbs(void)
+-{
+- /*
+- * Callbacks are RCU-protected and must be READ_ONCE to avoid reloading
+- * the callbacks between a !NULL check and dereferences, to ensure
+- * pending stores/changes to the callback pointers are visible before a
+- * non-NULL perf_guest_cbs is visible to readers, and to prevent a
+- * module from unloading callbacks while readers are active.
+- */
+- return rcu_dereference(perf_guest_cbs);
+-}
-extern int perf_register_guest_info_callbacks(struct perf_guest_info_callbacks *callbacks);
-extern int perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks *callbacks);
-
@@ -405105,7 +405116,7 @@
index 000000000000..e1e50f62fd8d
--- /dev/null
+++ b/include/linux/perf_event_api.h
-@@ -0,0 +1,1156 @@
+@@ -0,0 +1,1167 @@
+/*
+ * Performance events:
+ *
@@ -405863,7 +405874,18 @@
+ enum perf_bpf_event_type type,
+ u16 flags);
+
-+extern struct perf_guest_info_callbacks *perf_guest_cbs;
++extern struct perf_guest_info_callbacks __rcu *perf_guest_cbs;
++static inline struct perf_guest_info_callbacks *perf_get_guest_cbs(void)
++{
++ /*
++ * Callbacks are RCU-protected and must be READ_ONCE to avoid reloading
++ * the callbacks between a !NULL check and dereferences, to ensure
++ * pending stores/changes to the callback pointers are visible before a
++ * non-NULL perf_guest_cbs is visible to readers, and to prevent a
++ * module from unloading callbacks while readers are active.
++ */
++ return rcu_dereference(perf_guest_cbs);
++}
+extern int perf_register_guest_info_callbacks(struct perf_guest_info_callbacks *callbacks);
+extern int perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks *callbacks);
+
| Plz note this is minimalistic approach, only patching global patch file extracted as described above.
Thks 4 ur attention, interest & support. _________________ USE="-* ..." in /etc/portage/make.conf here. |
|
Back to top |
|
|
|