From: Minchan Kim <minchan@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jaewon Kim <jaewon31.kim@samsung.com>,
ngupta@vflare.org, senozhatsky@chromium.org,
avromanov@sberdevices.ru, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, s.suk@samsung.com,
ytk.lee@samsung.com, jaewon31.kim@gmail.com
Subject: Re: [PATCH] zram_drv: add __GFP_NOMEMALLOC not to use ALLOC_NO_WATERMARKS
Date: Mon, 6 Jun 2022 13:48:12 -0700 [thread overview]
Message-ID: <Yp5oDD8mfsGtsSaB@google.com> (raw)
In-Reply-To: <20220606125939.ae37867e43b8b8b07fa06ca7@linux-foundation.org>
On Mon, Jun 06, 2022 at 12:59:39PM -0700, Andrew Morton wrote:
> On Mon, 6 Jun 2022 12:46:38 -0700 Minchan Kim <minchan@kernel.org> wrote:
>
> > On Fri, Jun 03, 2022 at 02:57:47PM +0900, Jaewon Kim wrote:
> > > The atomic page allocation failure sometimes happened, and most of them
> > > seem to occur during boot time.
> > >
> > > <4>[ 59.707645] system_server: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=foreground-boost,mems_allowed=0
> >
> > ...
> >
> > >
> > > The kswapd or other reclaim contexts may not prepare enough free pages
> > > for too many atomic allocations occurred in short time. But zram may not
> > > be helpful for this atomic allocation even though zram is used to
> > > reclaim.
> > >
> > > To get one zs object for a specific size, zram may allocate serveral
> > > pages. And this can be happened on different class sizes at the same
> > > time. It means zram may consume more pages to reclaim only one page.
> > > This inefficiency may consume all free pages below watmerk min by a
> > > process having PF_MEMALLOC like kswapd.
> >
> > However, that's how zram has worked for a long time(allocate memory
> > under memory pressure) and many folks already have raised min_free_kbytes
> > when they use zram as swap. If we don't allow the allocation, swap out
> > fails easier than old, which would break existing tunes.
>
> So is there a better way of preventing this warning? Just suppress it
> with __GFP_NOWARN?
For me, I usually tries to remove GFP_ATOMIC alllocation since the
atomic allocation can be failed easily(zram is not only source for
it). Otherwise, increase min_free_kbytes?
next prev parent reply other threads:[~2022-06-06 20:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220603055341epcas1p2dd357326eea0cd818daf6f0db7c2aae1@epcas1p2.samsung.com>
2022-06-03 5:57 ` [PATCH] zram_drv: add __GFP_NOMEMALLOC not to use ALLOC_NO_WATERMARKS Jaewon Kim
2022-06-06 19:46 ` Minchan Kim
2022-06-06 19:59 ` Andrew Morton
2022-06-06 20:48 ` Minchan Kim [this message]
2022-06-07 1:17 ` Jaewon Kim
2022-06-07 23:47 ` Minchan Kim
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=Yp5oDD8mfsGtsSaB@google.com \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=avromanov@sberdevices.ru \
--cc=jaewon31.kim@gmail.com \
--cc=jaewon31.kim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ngupta@vflare.org \
--cc=s.suk@samsung.com \
--cc=senozhatsky@chromium.org \
--cc=ytk.lee@samsung.com \
/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.