From: Jakub Kicinski <kuba@kernel.org>
To: Coiby Xu <coxu@redhat.com>
Cc: netdev@vger.kernel.org, kexec@lists.infradead.org,
intel-wired-lan@lists.osuosl.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"David S. Miller" <davem@davemloft.net>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 4/4] i40e: don't open i40iw client for kdump
Date: Wed, 24 Feb 2021 08:48:41 -0800 [thread overview]
Message-ID: <20210224084841.50620776@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20210224114141.ziywca4dvn5fs6js@Rk>
On Wed, 24 Feb 2021 19:41:41 +0800 Coiby Xu wrote:
> On Tue, Feb 23, 2021 at 12:22:07PM -0800, Jakub Kicinski wrote:
> >On Mon, 22 Feb 2021 15:07:01 +0800 Coiby Xu wrote:
> >> i40iw consumes huge amounts of memory. For example, on a x86_64 machine,
> >> i40iw consumed 1.5GB for Intel Corporation Ethernet Connection X722 for
> >> for 1GbE while "craskernel=auto" only reserved 160M. With the module
> >> parameter "resource_profile=2", we can reduce the memory usage of i40iw
> >> to ~300M which is still too much for kdump.
> >>
> >> Disabling the client registration would spare us the client interface
> >> operation open , i.e., i40iw_open for iwarp/uda device. Thus memory is
> >> saved for kdump.
> >>
> >> Signed-off-by: Coiby Xu <coxu@redhat.com>
> >
> >Is i40iw or whatever the client is not itself under a CONFIG which
> >kdump() kernels could be reasonably expected to disable?
> >
>
> I'm not sure if I understand you correctly. Do you mean we shouldn't
> disable i40iw for kdump?
Forgive my ignorance - are the kdump kernels separate builds?
If they are it'd be better to leave the choice of enabling RDMA
to the user - through appropriate Kconfig options.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC PATCH 4/4] i40e: don't open i40iw client for kdump
Date: Wed, 24 Feb 2021 08:48:41 -0800 [thread overview]
Message-ID: <20210224084841.50620776@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20210224114141.ziywca4dvn5fs6js@Rk>
On Wed, 24 Feb 2021 19:41:41 +0800 Coiby Xu wrote:
> On Tue, Feb 23, 2021 at 12:22:07PM -0800, Jakub Kicinski wrote:
> >On Mon, 22 Feb 2021 15:07:01 +0800 Coiby Xu wrote:
> >> i40iw consumes huge amounts of memory. For example, on a x86_64 machine,
> >> i40iw consumed 1.5GB for Intel Corporation Ethernet Connection X722 for
> >> for 1GbE while "craskernel=auto" only reserved 160M. With the module
> >> parameter "resource_profile=2", we can reduce the memory usage of i40iw
> >> to ~300M which is still too much for kdump.
> >>
> >> Disabling the client registration would spare us the client interface
> >> operation open , i.e., i40iw_open for iwarp/uda device. Thus memory is
> >> saved for kdump.
> >>
> >> Signed-off-by: Coiby Xu <coxu@redhat.com>
> >
> >Is i40iw or whatever the client is not itself under a CONFIG which
> >kdump() kernels could be reasonably expected to disable?
> >
>
> I'm not sure if I understand you correctly. Do you mean we shouldn't
> disable i40iw for kdump?
Forgive my ignorance - are the kdump kernels separate builds?
If they are it'd be better to leave the choice of enabling RDMA
to the user - through appropriate Kconfig options.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Coiby Xu <coxu@redhat.com>
Cc: netdev@vger.kernel.org, kexec@lists.infradead.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
open list <linux-kernel@vger.kernel.org>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
intel-wired-lan@lists.osuosl.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC PATCH 4/4] i40e: don't open i40iw client for kdump
Date: Wed, 24 Feb 2021 08:48:41 -0800 [thread overview]
Message-ID: <20210224084841.50620776@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20210224114141.ziywca4dvn5fs6js@Rk>
On Wed, 24 Feb 2021 19:41:41 +0800 Coiby Xu wrote:
> On Tue, Feb 23, 2021 at 12:22:07PM -0800, Jakub Kicinski wrote:
> >On Mon, 22 Feb 2021 15:07:01 +0800 Coiby Xu wrote:
> >> i40iw consumes huge amounts of memory. For example, on a x86_64 machine,
> >> i40iw consumed 1.5GB for Intel Corporation Ethernet Connection X722 for
> >> for 1GbE while "craskernel=auto" only reserved 160M. With the module
> >> parameter "resource_profile=2", we can reduce the memory usage of i40iw
> >> to ~300M which is still too much for kdump.
> >>
> >> Disabling the client registration would spare us the client interface
> >> operation open , i.e., i40iw_open for iwarp/uda device. Thus memory is
> >> saved for kdump.
> >>
> >> Signed-off-by: Coiby Xu <coxu@redhat.com>
> >
> >Is i40iw or whatever the client is not itself under a CONFIG which
> >kdump() kernels could be reasonably expected to disable?
> >
>
> I'm not sure if I understand you correctly. Do you mean we shouldn't
> disable i40iw for kdump?
Forgive my ignorance - are the kdump kernels separate builds?
If they are it'd be better to leave the choice of enabling RDMA
to the user - through appropriate Kconfig options.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-02-24 16:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 7:06 [RFC PATCH 0/4] Reducing memory usage of i40e for kdump Coiby Xu
2021-02-22 7:06 ` Coiby Xu
2021-02-22 7:06 ` [Intel-wired-lan] " Coiby Xu
2021-02-22 7:06 ` [RFC PATCH 1/4] i40e: use minimal tx and rx pairs " Coiby Xu
2021-02-22 7:06 ` Coiby Xu
2021-02-22 7:06 ` [Intel-wired-lan] " Coiby Xu
2021-02-22 7:06 ` [RFC PATCH 2/4] i40e: use minimal rx and tx ring buffers " Coiby Xu
2021-02-22 7:06 ` Coiby Xu
2021-02-22 7:06 ` [Intel-wired-lan] " Coiby Xu
2021-02-22 7:07 ` [RFC PATCH 3/4] i40e: use minimal admin queue " Coiby Xu
2021-02-22 7:07 ` Coiby Xu
2021-02-22 7:07 ` [Intel-wired-lan] " Coiby Xu
2021-02-22 7:07 ` [RFC PATCH 4/4] i40e: don't open i40iw client " Coiby Xu
2021-02-22 7:07 ` Coiby Xu
2021-02-22 7:07 ` [Intel-wired-lan] " Coiby Xu
2021-02-23 20:22 ` Jakub Kicinski
2021-02-23 20:22 ` Jakub Kicinski
2021-02-23 20:22 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-24 11:41 ` Coiby Xu
2021-02-24 11:41 ` Coiby Xu
2021-02-24 11:41 ` [Intel-wired-lan] " Coiby Xu
2021-02-24 16:48 ` Jakub Kicinski [this message]
2021-02-24 16:48 ` Jakub Kicinski
2021-02-24 16:48 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-25 0:21 ` Coiby Xu
2021-02-25 0:21 ` Coiby Xu
2021-02-25 0:21 ` [Intel-wired-lan] " Coiby Xu
2021-02-25 0:47 ` Jakub Kicinski
2021-02-25 0:47 ` Jakub Kicinski
2021-02-25 0:47 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-25 10:11 ` Bhupesh SHARMA
2021-02-25 10:11 ` Bhupesh SHARMA
2021-02-25 10:11 ` [Intel-wired-lan] " Bhupesh SHARMA
2021-03-03 9:44 ` Coiby Xu
2021-03-03 9:44 ` Coiby Xu
2021-03-03 9:44 ` [Intel-wired-lan] " Coiby Xu
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=20210224084841.50620776@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=coxu@redhat.com \
--cc=davem@davemloft.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.