linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dongli Zhang <dongli.zhang@oracle.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, netdev@vger.kernel.org,
	Aruna Ramakrishna <aruna.ramakrishna@oracle.com>,
	Bert Barbe <bert.barbe@oracle.com>,
	Rama Nichanamatlu <rama.nichanamatlu@oracle.com>,
	Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>,
	Manjunath Patil <manjunath.b.patil@oracle.com>,
	Joe Jin <joe.jin@oracle.com>, SRINIVAS <srinivas.eeda@oracle.com>,
	stable@vger.kernel.org, vbabka@suse.cz
Subject: Re: [PATCH] page_frag: Recover from memory pressure
Date: Sat, 14 Nov 2020 22:47:33 -0800	[thread overview]
Message-ID: <615096a5-56df-6de3-6d2f-2028c259c2f0@oracle.com> (raw)
In-Reply-To: <a8dd751d-2777-6821-47d2-b3d11a569f70@gmail.com>

From linux-next, this patch is not in akpm branch.

According to discussion with Matthew offline, I will take the author of this
patch as Matthew was providing review for patch and suggesting a better
alternative.

Therefore, it will be much more easier or me to track this patch.

I will re-send the patch as v2 with:

1. change author from Matthew to Dongli
2. Add references to all prior discussions
3. Add more details to commit message so that it is much more easier to search
online when this issue is encountered by other people again.
4. Add "Acked-by: Vlastimil Babka <vbabka@suse.cz>".

Thank you very much!

Dongli Zhang

On 11/9/20 6:37 AM, Eric Dumazet wrote:
> 
> 
> On 11/9/20 3:32 PM, Matthew Wilcox wrote:
>> On Thu, Nov 05, 2020 at 02:02:24PM +0000, Matthew Wilcox wrote:
>>> On Thu, Nov 05, 2020 at 02:21:25PM +0100, Eric Dumazet wrote:
>>>> On 11/5/20 5:21 AM, Matthew Wilcox (Oracle) wrote:
>>>>> When the machine is under extreme memory pressure, the page_frag allocator
>>>>> signals this to the networking stack by marking allocations with the
>>>>> 'pfmemalloc' flag, which causes non-essential packets to be dropped.
>>>>> Unfortunately, even after the machine recovers from the low memory
>>>>> condition, the page continues to be used by the page_frag allocator,
>>>>> so all allocations from this page will continue to be dropped.
>>>>>
>>>>> Fix this by freeing and re-allocating the page instead of recycling it.
>>>>>
>>>>> Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
>>>>> Cc: Aruna Ramakrishna <aruna.ramakrishna@oracle.com>
>>>>> Cc: Bert Barbe <bert.barbe@oracle.com>
>>>>> Cc: Rama Nichanamatlu <rama.nichanamatlu@oracle.com>
>>>>> Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
>>>>> Cc: Manjunath Patil <manjunath.b.patil@oracle.com>
>>>>> Cc: Joe Jin <joe.jin@oracle.com>
>>>>> Cc: SRINIVAS <srinivas.eeda@oracle.com>
>>>>> Cc: stable@vger.kernel.org
>>>>> Fixes: 79930f5892e ("net: do not deplete pfmemalloc reserve")
>>>>
>>>> Your patch looks fine, although this Fixes: tag seems incorrect.
>>>>
>>>> 79930f5892e ("net: do not deplete pfmemalloc reserve") was propagating
>>>> the page pfmemalloc status into the skb, and seems correct to me.
>>>>
>>>> The bug was the page_frag_alloc() was keeping a problematic page for
>>>> an arbitrary period of time ?
>>>
>>> Isn't this the commit which unmasks the problem, though?  I don't think
>>> it's the buggy commit, but if your tree doesn't have 79930f5892e, then
>>> you don't need this patch.
>>>
>>> Or are you saying the problem dates back all the way to
>>> c93bdd0e03e8 ("netvm: allow skb allocation to use PFMEMALLOC reserves")
>>>
>>>>> +		if (nc->pfmemalloc) {
>>>>
>>>>                 if (unlikely(nc->pfmemalloc)) {
>>>
>>> ACK.  Will make the change once we've settled on an appropriate Fixes tag.
>>
>> Which commit should I claim this fixes?
> 
> Hmm, no big deal, lets not waste time on tracking precise bug origin.
> 


      reply	other threads:[~2020-11-15  6:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05  4:21 [PATCH] page_frag: Recover from memory pressure Matthew Wilcox (Oracle)
2020-11-05 11:56 ` Vlastimil Babka
2020-11-05 12:05   ` Matthew Wilcox
2020-11-05 12:09     ` Vlastimil Babka
2020-11-05 13:21 ` Eric Dumazet
2020-11-05 14:02   ` Matthew Wilcox
2020-11-09 14:32     ` Matthew Wilcox
2020-11-09 14:37       ` Eric Dumazet
2020-11-15  6:47         ` Dongli Zhang [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=615096a5-56df-6de3-6d2f-2028c259c2f0@oracle.com \
    --to=dongli.zhang@oracle.com \
    --cc=aruna.ramakrishna@oracle.com \
    --cc=bert.barbe@oracle.com \
    --cc=eric.dumazet@gmail.com \
    --cc=joe.jin@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=manjunath.b.patil@oracle.com \
    --cc=netdev@vger.kernel.org \
    --cc=rama.nichanamatlu@oracle.com \
    --cc=srinivas.eeda@oracle.com \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --cc=venkat.x.venkatsubra@oracle.com \
    --cc=willy@infradead.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).