From: Michal Hocko <mhocko@kernel.org>
To: Sangwoo <sangwoo2.park@lge.com>
Cc: hannes@cmpxchg.org, arunks@codeaurora.org, guro@fb.com,
richard.weiyang@gmail.com, glider@google.com, jannh@google.com,
dan.j.williams@intel.com, akpm@linux-foundation.org,
alexander.h.duyck@linux.intel.com, rppt@linux.vnet.ibm.com,
gregkh@linuxfoundation.org, janne.huttunen@nokia.com,
pasha.tatashin@soleen.com, vbabka@suse.cz, osalvador@suse.de,
mgorman@techsingularity.net, khlebnikov@yandex-team.ru,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: Add nr_free_highatomimic to fix incorrect watermatk routine
Date: Fri, 30 Aug 2019 13:09:07 +0200 [thread overview]
Message-ID: <20190830110907.GC28313@dhcp22.suse.cz> (raw)
In-Reply-To: <1567157153-22024-1-git-send-email-sangwoo2.park@lge.com>
On Fri 30-08-19 18:25:53, Sangwoo wrote:
> The highatomic migrate block can be increased to 1% of Total memory.
> And, this is for only highorder ( > 0 order). So, this block size is
> excepted during check watermark if allocation type isn't alloc_harder.
>
> It has problem. The usage of highatomic is already calculated at NR_FREE_PAGES.
> So, if we except total block size of highatomic, it's twice minus size of allocated
> highatomic.
> It's cause allocation fail although free pages enough.
>
> We checked this by random test on my target(8GB RAM).
>
> Binder:6218_2: page allocation failure: order:0, mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null)
> Binder:6218_2 cpuset=background mems_allowed=0
How come this order-0 sleepable allocation fails? The upstream kernel
doesn't fail those allocations unless the process context is killed by
the oom killer.
Also please note that atomic reserves are released when the memory
pressure is high and we cannot reclaim any other memory. Have a look at
unreserve_highatomic_pageblock called from should_reclaim_retry.
--
Michal Hocko
SUSE Labs
next parent reply other threads:[~2019-08-30 11:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1567157153-22024-1-git-send-email-sangwoo2.park@lge.com>
2019-08-30 11:09 ` Michal Hocko [this message]
2019-09-02 4:34 ` 박상우
2019-09-02 6:09 ` Michal Hocko
2019-09-05 13:59 ` Vlastimil Babka
2019-09-05 1:46 Park Sangwoo
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=20190830110907.GC28313@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=arunks@codeaurora.org \
--cc=dan.j.williams@intel.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=janne.huttunen@nokia.com \
--cc=jannh@google.com \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=richard.weiyang@gmail.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=sangwoo2.park@lge.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox