From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: Li RongQing <lirongqing@baidu.com>
Cc: <netdev@vger.kernel.org>, <intel-wired-lan@lists.osuosl.org>
Subject: Re: [PATCH][next] i40e: switch kvzalloc to allocate rx/tx_bi buffer
Date: Mon, 14 Sep 2020 16:22:44 -0700 [thread overview]
Message-ID: <20200914162244.00001783@intel.com> (raw)
In-Reply-To: <1598000514-5951-1-git-send-email-lirongqing@baidu.com>
Li RongQing wrote:
> when changes the rx/tx ring to 4096, rx/tx_bi needs an order
> 5 pages, and allocation maybe fail due to memory fragmentation
> so switch to kvzalloc
Hi Li,
Thanks for your patches, but I think you're solving a problem that isn't
a problem (besides that the warning is being printed.) After all, the
driver either gets the memory that it needed via the kernel waiting
(since we didn't set GFP_NOWAIT), or ENOMEM gets returned to the user.
If your kernel is so close to OOM that it's having this problem aren't
you going to have other issues? Anyway....
This driver goes to great lengths to not make any changes to the
existing queues if an allocation fails via ethtool (in fact this is
code I authored).
Maybe a better option is to just set __GFP_NOWARN on the kcalloc call?
Then if there is a memory allocation error we'll just reflect it to
user space and let the user retry, with no noisy kernel message.
For performance reasons, having actually contiguous regions from
kcalloc should help performance vs kvcalloc virtually contiguous
regions.
I'd prefer that you don't solve the problem this way. How about just
marking the allocations as GFP_RETRY_MAYFAIL and GFP_NOWARN?
The same goes for the iavf patch.
Jesse
prev parent reply other threads:[~2020-09-14 23:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 9:01 [PATCH][next] i40e: switch kvzalloc to allocate rx/tx_bi buffer Li RongQing
2020-09-04 21:48 ` Brown, Aaron F
2020-09-14 23:22 ` Jesse Brandeburg [this message]
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=20200914162244.00001783@intel.com \
--to=jesse.brandeburg@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=lirongqing@baidu.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).