Hi Coiby,
On Tue, 21 Jun 2022 14:57:26 +0800
Coiby Xu <coxu(a)redhat.com> wrote:
> Even after having asked NM to stop managing a unneeded NIC, a NIC driver
> may still wast memory. For example, mlx5_core uses a substantial amount
> of memory during driver initialization,
>
> ======== Report format module_summary: ========
> Module mlx5_core using 350.2MB (89650 pages), peak allocation 367.4MB (94056 pages)
> Module squashfs using 13.1MB (3360 pages), peak allocation 13.1MB (3360 pages)
> Module overlay using 2.1MB (550 pages), peak allocation 2.2MB (555 pages)
> Module dns_resolver using 0.9MB (219 pages), peak allocation 5.2MB (1338 pages)
> Module mlxfw using 0.7MB (172 pages), peak allocation 5.3MB (1349 pages)
> ======== Report format module_summary END ========
>
> ======== Report format module_top: ========
> Top stack usage of module mlx5_core:
> (null) Pages: 89650 (peak: 94056)
> ret_from_fork (0xffffda088b4165f8) Pages: 60007 (peak: 60007)
> kthread (0xffffda088b4bd7e4) Pages: 60007 (peak: 60007)
> worker_thread (0xffffda088b4b48d0) Pages: 60007 (peak: 60007)
> process_one_work (0xffffda088b4b3f40) Pages: 60007 (peak: 60007)
> work_for_cpu_fn (0xffffda088b4aef00) Pages: 53906 (peak: 53906)
> local_pci_probe (0xffffda088b9e1e44) Pages: 53906 (peak: 53906)
> probe_one mlx5_core (0xffffda084f899cc8) Pages: 53518 (peak: 53518)
> mlx5_init_one mlx5_core (0xffffda084f8994ac) Pages: 49756 (peak:
49756)
> mlx5_function_setup.constprop.0 mlx5_core (0xffffda084f899100)
Pages: 44434 (eak: 44434)
> mlx5_satisfy_startup_pages mlx5_core (0xffffda084f8a4f24)
Pages: 44434 (peak: 44434)
> mlx5_function_setup.constprop.0 mlx5_core (0xffffda084f899078)
Pages: 5285 (peak: 5285)
> mlx5_cmd_init mlx5_core (0xffffda084f89e414) Pages: 4818 (peak:
4818)
> mlx5_alloc_cmd_msg mlx5_core (0xffffda084f89aaa0) Pages: 4403
(peak: 4403)
>
> This memory consumption is completely unnecessary is kdump doesn't need
s/is/if/ or maybe even better 'when'
> this NIC. Only install needed NIC drivers to prevent this kind of waste.
>
> Note
> 1. this patch depends on [1] to ask dracut to not install NIC drivers.
> 2. "ethtool -i" somehows fails to get the vlan driver
> 3. team.ko doesn't depend on the team mode drivers so we need to install
> the team mode drivers manually.
>
> [1]
https://github.com/dracutdevs/dracut/pull/1789
>
> Signed-off-by: Coiby Xu <coxu(a)redhat.com>
> ---
> dracut-module-setup.sh | 32 +++++++++++++++++++++++++++++++-
> mkdumprd | 2 +-
> 2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index 2a15e5e..d5bec47 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -324,6 +324,35 @@ kdump_install_nm_netif_allowlist() {
> inst "$_netif_allowlist_nm_conf"
"/etc/NetworkManager/conf.d/10-kdump-netif.conf"
> }
>
> +_get_nic_driver() {
> + ethtool -i "$1" | sed -n -E "s/driver: (.*)/\1/p"
> +}
> +
> +kdump_install_nic_driver() {
> + local _netif _driver _drivers
> +
> + for _netif in $1; do
> + _driver=$(_get_nic_driver "$_netif")
> + if [[ -z $_driver ]]; then
> + derror "Failed to get the driver of $_netif"
> + exit 1
> + fi
> +
> + if [[ $_driver == "802.1Q VLAN Support" ]]; then
> + # ethtool somehow doesn't return the driver name for a VLAN NIC
> + _driver=8021q
> + elif [[ $_driver == "team" ]]; then
> + # install the team mode drivers like team_mode_roundrobin.ko as well
> + _driver='=drivers/net/team'
> + fi
> +
> + _drivers="$_drivers $_driver"
> + done
> +
> + # shellcheck disable=SC2086 # split the argument to have a list of drivers
> + instmods $_drivers
Instead of disabling shellcheck here you could convert drivers into an
array as it is explained in [1] under 'Exceptions'
[1]
https://www.shellcheck.net/wiki/SC2086
> +}
> +
> kdump_setup_bridge() {
> local _netdev=$1
> local _dev
> @@ -994,8 +1023,9 @@ install() {
> fi
>
> _netifs=$(cat "$_TMP_KDUMP_NETIFS")
> - if [[ -n "$_netif_allowlist" ]]; then
> + if [[ -n "$_netifs" ]]; then
I believe this fix should go into the previous patch.
Good catch! All the three issues have been fixed in v2. Thanks!
--
Best regards,
Coiby