From: David Hildenbrand <david@redhat.com>
To: Luis Chamberlain <mcgrof@kernel.org>,
Adam Manzanares <a.manzanares@samsung.com>
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
pmladek@suse.com, petr.pavlu@suse.com, prarit@redhat.com,
christophe.leroy@csgroup.eu, song@kernel.org,
torvalds@linux-foundation.org
Subject: Re: [RFC 00/12] module: avoid userspace pressure on unwanted allocations
Date: Fri, 24 Mar 2023 10:27:14 +0100 [thread overview]
Message-ID: <582aa586-e69c-99bb-caf8-eda468c332b6@redhat.com> (raw)
In-Reply-To: <bb6e15e0-2831-6352-82c8-92648a29fb0b@redhat.com>
On 21.03.23 20:32, David Hildenbrand wrote:
> On 20.03.23 22:27, Luis Chamberlain wrote:
>> On Mon, Mar 20, 2023 at 02:23:36PM -0700, Luis Chamberlain wrote:
>>> On Mon, Mar 20, 2023 at 10:15:23PM +0100, David Hildenbrand wrote:
>>>> Not able to reproduce with 20230319-module-alloc-opts so far (2 tries).
>>>
>>> Oh wow, so to clarify, it boots OK?
>>>
>>
>> Now that we know that tree works, I'm curious also now if you can
>> confirm just re-ordering the patches still works (it should)
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20230319-module-alloc-opts-adjust
>>
>
> So far no vmap errors booting the debug/kasan kernel (2 tries).
>
>> And although it's *probably* just noise, but I'm very curious how much,
>> if any difference there is if you just revert "module: use
>> list_add_tail_rcu() when adding module".
>
> Dito, no vmap errors booting the debug/kasan kernel (2 tries).
>
>>
>> The data on that commit log is pretty small as I have a low end system,
>> and I'm not yet done beating the hell out of a system with stress-ng,
>> but getting some data froma pretty large system would be great.
>> Specially if this series seems to prove fixing boot on them.
>
> 2x booting RHEL9.1 on a !debug kernel. Something went wrong with kdump in 2 runs (think I
> had to delete the kdump initrd to make space for another kernel), but we can just mostly
> ignore that. I wanted to rerun with kdump disabled completely, but I'm out of time for today.
>
>
> 1) v6.3-rc1:
>
> #1
>
> Startup finished in 25.354s (kernel) + 7.662s (initrd) + 1min 8.805s (userspace) = 1min 41.822s
> multi-user.target reached after 29.186s in userspace
>
> 47.178s kdump.service
> 14.898s tuned.service
> 11.394s chrony-wait.service
> 7.486s systemd-udev-settle.service
> 7.334s NetworkManager-wait-online.service
> 2.908s initrd-switch-root.service
> 2.451s smartd.service
> 2.316s dracut-initqueue.service
> 2.057s polkit.service
> 1.290s NetworkManager.service
> 1.046s cups.service
> ...
>
> #2
>
> Startup finished in 25.375s (kernel) + 7.497s (initrd) + 29.428s (userspace) = 1min 2.301s
> multi-user.target reached after 29.392s in userspace
>
> 14.552s tuned.service
> 9.410s chrony-wait.service
> 8.126s systemd-udev-settle.service
> 7.502s NetworkManager-wait-online.service
> 2.871s initrd-switch-root.service
> 2.401s kdump.service
> 2.297s polkit.service
> 2.116s dracut-initqueue.service
> 2.027s smartd.service
> 1.262s NetworkManager.service
> 1.102s cups.service
> 1.011s sshd.service
> ...
>
>
> 2) 20230319-module-alloc-opts-adjust + revert of list_add_tail_rcu():
>
> #1
>
> Startup finished in 25.441s (kernel) + 7.285s (initrd) + 1min 7.644s (userspace) = 1min 40.371s
> multi-user.target reached after 27.213s in userspace
>
> 47.232s kdump.service
> 14.235s tuned.service
> 8.220s chrony-wait.service
> 7.444s NetworkManager-wait-online.service
> 5.986s systemd-udev-settle.service
> 2.881s initrd-switch-root.service
> 2.236s smartd.service
> 1.899s dracut-initqueue.service
> 1.812s polkit.service
> 1.554s NetworkManager.service
> 1.140s ModemManager.service
> ...
>
> #2
>
> Startup finished in 25.377s (kernel) + 7.271s (initrd) + 28.247s (userspace) = 1min 897ms
> multi-user.target reached after 28.210s in userspace
>
> 15.435s tuned.service
> 11.365s chrony-wait.service
> 7.512s NetworkManager-wait-online.service
> 5.962s systemd-udev-settle.service
> 2.889s initrd-switch-root.service
> 2.846s smartd.service
> 2.819s kdump.service
> 2.228s polkit.service
> 1.872s dracut-initqueue.service
> 1.312s NetworkManager.service
> 1.152s ModemManager.service
> 1.011s sshd.service
> ...
>
> 3) 20230319-module-alloc-opts-adjust:
>
>
> #1
>
> Startup finished in 25.320s (kernel) + 7.192s (initrd) + 1min 6.511s (userspace) = 1min 39.024s
> multi-user.target reached after 28.205s in userspace
>
> 46.307s kdump.service
> 14.199s tuned.service
> 13.358s chrony-wait.service
> 7.468s NetworkManager-wait-online.service
> 6.329s systemd-udev-settle.service
> 2.910s initrd-switch-root.service
> 2.752s smartd.service
> 2.142s polkit.service
> 1.909s dracut-initqueue.service
> 1.210s NetworkManager.service
> 1.041s ModemManager.service
> 925ms sshd.service
> ...
>
> #2
>
> Startup finished in 25.368s (kernel) + 7.303s (initrd) + 1min 6.897s (userspace) = 1min 39.569s
> multi-user.target reached after 27.326s in userspace
>
> 45.626s kdump.service
> 14.707s tuned.service
> 13.246s chrony-wait.service
> 7.428s NetworkManager-wait-online.service
> 6.507s systemd-udev-settle.service
> 3.038s initrd-switch-root.service
> 3.001s smartd.service
> 2.057s polkit.service
> 1.746s dracut-initqueue.service
> 1.221s NetworkManager.service
> ...
>
>
> I think we primarily only care about systemd-udev-settle.service.
>
> That is fastest without the rcu patch (~6s), compared to with the rcu
> patch (~6.5s) and with stock (~7.5s -- 8s).
>
> Looks like dracut-initqueue also might be a bit faster with your changes, but
> maybe it's mostly noise (would have to do more runs).
>
> So maybe drop that rcu patch? But of course, there could be other scenarios where it's
> helpful ...
Are there any other things you would like me to measure/test? I'll have
to hand back that test machine soonish.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2023-03-24 9:28 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-11 5:17 [RFC 00/12] module: avoid userspace pressure on unwanted allocations Luis Chamberlain
2023-03-11 5:17 ` [RFC 01/12] module: use goto errors on check_modinfo() and layout_and_allocate() Luis Chamberlain
2023-03-11 5:17 ` [RFC 02/12] module: move get_modinfo() helpers all above Luis Chamberlain
2023-03-11 5:17 ` [RFC 03/12] module: rename next_string() to module_next_tag_pair() Luis Chamberlain
2023-03-11 5:17 ` [RFC 04/12] module: add a for_each_modinfo_entry() Luis Chamberlain
2023-03-11 5:17 ` [RFC 05/12] module: add debugging alias parsing support Luis Chamberlain
2023-03-11 5:17 ` [RFC 06/12] module: move early sanity checks into a helper Luis Chamberlain
2023-03-11 5:17 ` [RFC 07/12] module: move check_modinfo() early to early_mod_check() Luis Chamberlain
2023-03-11 5:17 ` [RFC 08/12] module: move finished_loading() Luis Chamberlain
2023-03-11 5:17 ` [RFC 09/12] module: extract patient module check into helper Luis Chamberlain
2023-03-11 5:17 ` [RFC 10/12] module: avoid allocation if module is already present and ready Luis Chamberlain
2023-03-11 5:17 ` [RFC 11/12] module: use list_add_tail_rcu() when adding module Luis Chamberlain
2023-03-11 5:17 ` [RFC 12/12] module: use aliases to find module on find_module_all() Luis Chamberlain
2023-03-15 14:43 ` Petr Pavlu
2023-03-15 16:12 ` Luis Chamberlain
2023-03-15 12:24 ` [RFC 00/12] module: avoid userspace pressure on unwanted allocations David Hildenbrand
2023-03-15 16:10 ` Luis Chamberlain
2023-03-15 16:41 ` David Hildenbrand
2023-03-16 23:55 ` Luis Chamberlain
2023-03-16 23:56 ` Luis Chamberlain
2023-03-18 0:11 ` Luis Chamberlain
2023-03-20 9:38 ` David Hildenbrand
2023-03-20 19:40 ` David Hildenbrand
2023-03-20 21:09 ` Luis Chamberlain
2023-03-20 21:15 ` David Hildenbrand
2023-03-20 21:23 ` Luis Chamberlain
2023-03-20 21:27 ` Luis Chamberlain
2023-03-21 19:32 ` David Hildenbrand
2023-03-24 9:27 ` David Hildenbrand [this message]
2023-03-24 17:54 ` Luis Chamberlain
2023-03-24 19:11 ` Linus Torvalds
2023-03-24 19:59 ` Luis Chamberlain
2023-03-24 20:28 ` Linus Torvalds
2023-03-24 21:14 ` Luis Chamberlain
2023-03-24 23:27 ` Luis Chamberlain
2023-03-24 23:41 ` Linus Torvalds
2023-03-28 3:44 ` David Hildenbrand
2023-03-28 6:16 ` Luis Chamberlain
2023-03-28 21:02 ` David Hildenbrand
2023-03-29 5:31 ` Luis Chamberlain
2023-03-30 4:42 ` David Hildenbrand
2023-03-21 15:11 ` David Hildenbrand
2023-03-21 16:52 ` Luis Chamberlain
2023-03-21 17:01 ` David Hildenbrand
2023-03-20 9:37 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=582aa586-e69c-99bb-caf8-eda468c332b6@redhat.com \
--to=david@redhat.com \
--cc=a.manzanares@samsung.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=pmladek@suse.com \
--cc=prarit@redhat.com \
--cc=song@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox