linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: yangge1116@126.com, akpm@linux-foundation.org
Cc: oe-kbuild-all@lists.linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	21cnbao@gmail.com, david@redhat.com,
	baolin.wang@linux.alibaba.com, vbabka@suse.cz,
	liuzixing@hygon.cn, yangge <yangge1116@126.com>
Subject: Re: [PATCH V2] mm, compaction: don't use ALLOC_CMA in long term GUP flow
Date: Sun, 15 Dec 2024 11:29:07 +0800	[thread overview]
Message-ID: <202412151139.n93obAio-lkp@intel.com> (raw)
In-Reply-To: <1734157420-31110-1-git-send-email-yangge1116@126.com>

Hi,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]

url:    https://github.com/intel-lab-lkp/linux/commits/yangge1116-126-com/mm-compaction-don-t-use-ALLOC_CMA-in-long-term-GUP-flow/20241214-142453
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/1734157420-31110-1-git-send-email-yangge1116%40126.com
patch subject: [PATCH V2] mm, compaction: don't use ALLOC_CMA in long term GUP flow
config: i386-buildonly-randconfig-004-20241215 (https://download.01.org/0day-ci/archive/20241215/202412151139.n93obAio-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241215/202412151139.n93obAio-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202412151139.n93obAio-lkp@intel.com/

All errors (new ones prefixed by >>):

   mm/vmscan.c: In function 'should_continue_reclaim':
>> mm/vmscan.c:5822:21: error: too many arguments to function 'compaction_suitable'
    5822 |                 if (compaction_suitable(zone, sc->order, sc->reclaim_idx, 0))
         |                     ^~~~~~~~~~~~~~~~~~~
   In file included from mm/vmscan.c:36:
   include/linux/compaction.h:111:20: note: declared here
     111 | static inline bool compaction_suitable(struct zone *zone, int order,
         |                    ^~~~~~~~~~~~~~~~~~~
   mm/vmscan.c: In function 'compaction_ready':
   mm/vmscan.c:6050:14: error: too many arguments to function 'compaction_suitable'
    6050 |         if (!compaction_suitable(zone, sc->order, sc->reclaim_idx, 0))
         |              ^~~~~~~~~~~~~~~~~~~
   include/linux/compaction.h:111:20: note: declared here
     111 | static inline bool compaction_suitable(struct zone *zone, int order,
         |                    ^~~~~~~~~~~~~~~~~~~


vim +/compaction_suitable +5822 mm/vmscan.c

  5778	
  5779	/*
  5780	 * Reclaim/compaction is used for high-order allocation requests. It reclaims
  5781	 * order-0 pages before compacting the zone. should_continue_reclaim() returns
  5782	 * true if more pages should be reclaimed such that when the page allocator
  5783	 * calls try_to_compact_pages() that it will have enough free pages to succeed.
  5784	 * It will give up earlier than that if there is difficulty reclaiming pages.
  5785	 */
  5786	static inline bool should_continue_reclaim(struct pglist_data *pgdat,
  5787						unsigned long nr_reclaimed,
  5788						struct scan_control *sc)
  5789	{
  5790		unsigned long pages_for_compaction;
  5791		unsigned long inactive_lru_pages;
  5792		int z;
  5793	
  5794		/* If not in reclaim/compaction mode, stop */
  5795		if (!in_reclaim_compaction(sc))
  5796			return false;
  5797	
  5798		/*
  5799		 * Stop if we failed to reclaim any pages from the last SWAP_CLUSTER_MAX
  5800		 * number of pages that were scanned. This will return to the caller
  5801		 * with the risk reclaim/compaction and the resulting allocation attempt
  5802		 * fails. In the past we have tried harder for __GFP_RETRY_MAYFAIL
  5803		 * allocations through requiring that the full LRU list has been scanned
  5804		 * first, by assuming that zero delta of sc->nr_scanned means full LRU
  5805		 * scan, but that approximation was wrong, and there were corner cases
  5806		 * where always a non-zero amount of pages were scanned.
  5807		 */
  5808		if (!nr_reclaimed)
  5809			return false;
  5810	
  5811		/* If compaction would go ahead or the allocation would succeed, stop */
  5812		for (z = 0; z <= sc->reclaim_idx; z++) {
  5813			struct zone *zone = &pgdat->node_zones[z];
  5814			if (!managed_zone(zone))
  5815				continue;
  5816	
  5817			/* Allocation can already succeed, nothing to do */
  5818			if (zone_watermark_ok(zone, sc->order, min_wmark_pages(zone),
  5819					      sc->reclaim_idx, 0))
  5820				return false;
  5821	
> 5822			if (compaction_suitable(zone, sc->order, sc->reclaim_idx, 0))
  5823				return false;
  5824		}
  5825	
  5826		/*
  5827		 * If we have not reclaimed enough pages for compaction and the
  5828		 * inactive lists are large enough, continue reclaiming
  5829		 */
  5830		pages_for_compaction = compact_gap(sc->order);
  5831		inactive_lru_pages = node_page_state(pgdat, NR_INACTIVE_FILE);
  5832		if (can_reclaim_anon_pages(NULL, pgdat->node_id, sc))
  5833			inactive_lru_pages += node_page_state(pgdat, NR_INACTIVE_ANON);
  5834	
  5835		return inactive_lru_pages > pages_for_compaction;
  5836	}
  5837	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


  reply	other threads:[~2024-12-15  3:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-14  6:23 yangge1116
2024-12-15  3:29 ` kernel test robot [this message]
2024-12-15  5:32 ` kernel test robot

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=202412151139.n93obAio-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuzixing@hygon.cn \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --cc=yangge1116@126.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox