[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y7PaxPV3Ln7AXVSc@lucifer>
Date: Tue, 3 Jan 2023 07:35:32 +0000
From: Lorenzo Stoakes <lstoakes@...il.com>
To: Jaewon Kim <jaewon31.kim@...sung.com>
Cc: riel@...hat.com, redkoi@...tuozzo.com, akpm@...ux-foundation.org,
hannes@...xchg.org, mhocko@...nel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, jaewon31.kim@...il.com
Subject: Re: [PATCH] page_alloc: avoid the negative free for meminfo available
On Tue, Jan 03, 2023 at 04:28:07PM +0900, Jaewon Kim wrote:
> The totalreserve_pages could be higher than the free because of
> watermark high or watermark boost. Handle this situation and fix it to 0
> free size.
>
> Signed-off-by: Jaewon Kim <jaewon31.kim@...sung.com>
> ---
> mm/page_alloc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 218b28ee49ed..e510ae83d5f3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5948,6 +5948,8 @@ long si_mem_available(void)
> * without causing swapping or OOM.
> */
> available = global_zone_page_state(NR_FREE_PAGES) - totalreserve_pages;
> + if (available < 0)
> + available = 0;
>
> /*
> * Not all the page cache can be freed, otherwise the system will
> --
> 2.17.1
>
We already reset to zero at the end of the function, wouldn't resetting to zero
here potentially skew the result?
Powered by blists - more mailing lists