[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d531e69c-f0b4-f857-657f-48d981db3923@quicinc.com>
Date: Thu, 16 Nov 2023 11:30:04 +0530
From: Charan Teja Kalla <quic_charante@...cinc.com>
To: Michal Hocko <mhocko@...e.com>
CC: <akpm@...ux-foundation.org>, <mgorman@...hsingularity.net>,
<david@...hat.com>, <vbabka@...e.cz>, <hannes@...xchg.org>,
<quic_pkondeti@...cinc.com>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 3/3] mm: page_alloc: drain pcp lists before oom kill
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 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.
Thanks,
Charan
Powered by blists - more mailing lists