From: kernel test robot <lkp@intel.com>
To: Aaron Tomlin <atomlin@redhat.com>, linux-mm@kvack.org
Cc: kbuild-all@lists.01.org, clang-built-linux@googlegroups.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: try oom if reclaim is unable to make forward progress
Date: Tue, 16 Mar 2021 03:54:31 +0800 [thread overview]
Message-ID: <202103160346.k4PPckDF-lkp@intel.com> (raw)
In-Reply-To: <20210315165837.789593-1-atomlin@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 7161 bytes --]
Hi Aaron,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hnaz-linux-mm/master]
url: https://github.com/0day-ci/linux/commits/Aaron-Tomlin/mm-page_alloc-try-oom-if-reclaim-is-unable-to-make-forward-progress/20210316-010203
base: https://github.com/hnaz/linux-mm master
config: powerpc64-randconfig-r012-20210315 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project a28facba1ccdc957f386b7753f4958307f1bfde8)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# https://github.com/0day-ci/linux/commit/77338aaff2606a7715c832545e79370e849e3b4e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Aaron-Tomlin/mm-page_alloc-try-oom-if-reclaim-is-unable-to-make-forward-progress/20210316-010203
git checkout 77338aaff2606a7715c832545e79370e849e3b4e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mm/page_alloc.c:2538:5: warning: no previous prototype for function 'find_suitable_fallback' [-Wmissing-prototypes]
int find_suitable_fallback(struct free_area *area, unsigned int order,
^
mm/page_alloc.c:2538:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int find_suitable_fallback(struct free_area *area, unsigned int order,
^
static
>> mm/page_alloc.c:4444:3: error: use of undeclared identifier 'result'
result false;
^
>> mm/page_alloc.c:4447:50: error: expected ';' after return statement
return unreserve_highatomic_pageblock(ac, true)
^
;
>> mm/page_alloc.c:4507:2: error: expected expression
else
^
>> mm/page_alloc.c:4719:6: error: implicit declaration of function 'should_try_oom' [-Werror,-Wimplicit-function-declaration]
if (should_try_oom(no_progress_loops, compact_result))
^
>> mm/page_alloc.c:4720:11: error: expected ';' after goto statement
goto oom:
^
;
mm/page_alloc.c:6136:23: warning: no previous prototype for function 'memmap_init' [-Wmissing-prototypes]
void __meminit __weak memmap_init(unsigned long size, int nid,
^
mm/page_alloc.c:6136:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void __meminit __weak memmap_init(unsigned long size, int nid,
^
static
2 warnings and 5 errors generated.
vim +/result +4444 mm/page_alloc.c
4409
4410 /*
4411 * Checks whether it makes sense to retry the reclaim to make a forward progress
4412 * for the given allocation request.
4413 *
4414 * We give up when we either have tried MAX_RECLAIM_RETRIES in a row
4415 * without success, or when we couldn't even meet the watermark if we
4416 * reclaimed all remaining pages on the LRU lists.
4417 *
4418 * Returns true if a retry is viable or false to enter the oom path.
4419 */
4420 static inline bool
4421 should_reclaim_retry(gfp_t gfp_mask, unsigned order,
4422 struct alloc_context *ac, int alloc_flags,
4423 bool did_some_progress, int *no_progress_loops)
4424 {
4425 struct zone *zone;
4426 struct zoneref *z;
4427 bool ret = false;
4428
4429 /*
4430 * Costly allocations might have made a progress but this doesn't mean
4431 * their order will become available due to high fragmentation so
4432 * always increment the no progress counter for them
4433 */
4434 if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER)
4435 *no_progress_loops = 0;
4436 else
4437 (*no_progress_loops)++;
4438
4439 /*
4440 * Make sure we converge to OOM if we cannot make any progress
4441 * several times in the row.
4442 */
4443 if (*no_progress_loops > MAX_RECLAIM_RETRIES)
> 4444 result false;
4445 /* Last chance before OOM, try draining highatomic_reserve once */
4446 else if (*no_progress_loops == MAX_RECLAIM_RETRIES)
> 4447 return unreserve_highatomic_pageblock(ac, true)
4448
4449 /*
4450 * Keep reclaiming pages while there is a chance this will lead
4451 * somewhere. If none of the target zones can satisfy our allocation
4452 * request even if all reclaimable pages are considered then we are
4453 * screwed and have to go OOM.
4454 */
4455 for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
4456 ac->highest_zoneidx, ac->nodemask) {
4457 unsigned long available;
4458 unsigned long reclaimable;
4459 unsigned long min_wmark = min_wmark_pages(zone);
4460 bool wmark;
4461
4462 available = reclaimable = zone_reclaimable_pages(zone);
4463 available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
4464
4465 /*
4466 * Would the allocation succeed if we reclaimed all
4467 * reclaimable pages?
4468 */
4469 wmark = __zone_watermark_ok(zone, order, min_wmark,
4470 ac->highest_zoneidx, alloc_flags, available);
4471 trace_reclaim_retry_zone(z, order, reclaimable,
4472 available, min_wmark, *no_progress_loops, wmark);
4473 if (wmark) {
4474 /*
4475 * If we didn't make any progress and have a lot of
4476 * dirty + writeback pages then we should wait for
4477 * an IO to complete to slow down the reclaim and
4478 * prevent from pre mature OOM
4479 */
4480 if (!did_some_progress) {
4481 unsigned long write_pending;
4482
4483 write_pending = zone_page_state_snapshot(zone,
4484 NR_ZONE_WRITE_PENDING);
4485
4486 if (2 * write_pending > reclaimable) {
4487 congestion_wait(BLK_RW_ASYNC, HZ/10);
4488 return true;
4489 }
4490 }
4491
4492 ret = true;
4493 goto out;
4494 }
4495 }
4496
4497 out:
4498 /*
4499 * Memory allocation/reclaim might be called from a WQ context and the
4500 * current implementation of the WQ concurrency control doesn't
4501 * recognize that a particular WQ is congested if the worker thread is
4502 * looping without ever sleeping. Therefore we have to do a short sleep
4503 * here rather than calling cond_resched().
4504 */
4505 if (current->flags & PF_WQ_WORKER)
4506 schedule_timeout_uninterruptible(1);
> 4507 else
4508 cond_resched();
4509 return ret;
4510 }
4511
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30238 bytes --]
next prev parent reply other threads:[~2021-03-15 19:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 16:58 [PATCH] mm/page_alloc: try oom if reclaim is unable to make forward progress Aaron Tomlin
2021-03-15 19:54 ` kernel test robot [this message]
2021-03-15 19:54 ` kernel test robot
2021-03-15 19:54 ` kernel test robot
2021-03-18 16:16 ` Michal Hocko
2021-03-19 17:29 ` Aaron Tomlin
2021-03-22 10:47 ` Michal Hocko
2021-03-25 21:01 ` Aaron Tomlin
2021-03-26 8:16 ` Michal Hocko
2021-03-26 11:22 ` Aaron Tomlin
2021-03-26 15:36 ` Michal Hocko
2021-03-26 17:00 ` Aaron Tomlin
2021-05-18 14:05 ` Aaron Tomlin
2021-05-19 11:10 ` Michal Hocko
2021-05-19 13:06 ` Aaron Tomlin
2021-05-19 14:50 ` [PATCH] mm/page_alloc: bail out on fatal signal during reclaim/compaction retry attempt Aaron Tomlin
2021-05-19 15:22 ` Vlastimil Babka
2021-05-19 19:08 ` Aaron Tomlin
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=202103160346.k4PPckDF-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=atomlin@redhat.com \
--cc=clang-built-linux@googlegroups.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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;
as well as URLs for NNTP newsgroup(s).