All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: akpm@linux-foundation.org, mgorman@techsingularity.net,
	david@redhat.com, vbabka@suse.cz, hannes@cmpxchg.org,
	quic_pkondeti@quicinc.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 3/3] mm: page_alloc: drain pcp lists before oom kill
Date: Thu, 16 Nov 2023 13:55:00 +0100	[thread overview]
Message-ID: <ZVYRJMUitykepLRy@tiehlicka> (raw)
In-Reply-To: <d531e69c-f0b4-f857-657f-48d981db3923@quicinc.com>

On Thu 16-11-23 11:30:04, Charan Teja Kalla wrote:
> Thanks Michal.
> 
> On 11/15/2023 7:39 PM, Michal Hocko wrote:
> >> Also If you have any comments on [PATCH V2 2/3] mm: page_alloc: correct
> >> high atomic reserve calculations will help me.
> > I do not have a strong opinion on that one to be honest. I am not even
> > sure that reserving a full page block (4MB) on small systems as
> > presented is really a good use of memory.
> 
> May be other way to look at that patch is comment is really not being
> reflected in the code. It says, " Limit the number reserved to 1
> pageblock or roughly 1% of a zone.", but the current code is making it 2
> pageblocks. So, for 4M block size, it is > 1%.
> 
> A second patch, that I will post, like not reserving the high atomic
> page blocks on small systems -- But how to define the meaning of small
> systems is not sure. Instead will let the system administrators chose
> this through either:
> a) command line param, high_atomic_reserves=off, on by default --
> Another knob, so admins may really not like this?
> b) CONFIG_HIGH_ATOMIC_RESERVES, which if not defined, will not reserve.

Please don't! I do not see any admin wanting to care about this at all.
It just takes a lot of understanding of internal MM stuff to make an
educated guess. This should really be auto-tuned. And as responded in
other reply my take would be to reserve a page block on if it doesn't
consume more than 1% of memory to preserve the existing behavior yet not
overconsume on small systems.
 
> Please lmk If you have any more suggestions here?
> 
> Also, I am thinking to request Andrew to pick [PATCH V2 1/3] patch and
> take these discussions separately in a separate thread.

That makes sense as that is a clear bug fix.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2023-11-16 12:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-05 12:50 [PATCH V2 0/3] mm: page_alloc: fixes for early oom kills Charan Teja Kalla
2023-11-05 12:50 ` [PATCH V2 1/3] mm: page_alloc: unreserve highatomic page blocks before oom Charan Teja Kalla
2023-11-09 10:29   ` Michal Hocko
2023-11-05 12:50 ` [PATCH V2 2/3] mm: page_alloc: correct high atomic reserve calculations Charan Teja Kalla
2023-11-16  9:59   ` Mel Gorman
2023-11-16 12:52     ` Michal Hocko
2023-11-17 16:19       ` Mel Gorman
2023-11-05 12:50 ` [PATCH V3 3/3] mm: page_alloc: drain pcp lists before oom kill Charan Teja Kalla
2023-11-05 12:55   ` Charan Teja Kalla
2023-11-09 10:33   ` Michal Hocko
2023-11-10 16:36     ` Charan Teja Kalla
2023-11-14 10:48       ` Michal Hocko
2023-11-14 16:36         ` Charan Teja Kalla
2023-11-15 14:09           ` Michal Hocko
2023-11-16  6:00             ` Charan Teja Kalla
2023-11-16 12:55               ` Michal Hocko [this message]
2023-11-17  5:43                 ` Charan Teja Kalla
2024-01-25 16:36           ` Zach O'Keefe
2024-01-26 10:47             ` Charan Teja Kalla
2024-01-26 10:57               ` Michal Hocko
2024-01-26 22:51                 ` Zach O'Keefe
2024-01-29 15:04                   ` Michal Hocko
2024-02-06 23:15                     ` Zach O'Keefe

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=ZVYRJMUitykepLRy@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=quic_charante@quicinc.com \
    --cc=quic_pkondeti@quicinc.com \
    --cc=vbabka@suse.cz \
    /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.