lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202409140533.2vt8QPj8-lkp@intel.com>
Date: Sat, 14 Sep 2024 05:53:55 +0800
From: kernel test robot <lkp@...el.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>, tj@...nel.org,
	cgroups@...r.kernel.org, yosryahmed@...gle.com,
	shakeel.butt@...ux.dev
Cc: llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
	Jesper Dangaard Brouer <hawk@...nel.org>, hannes@...xchg.org,
	lizefan.x@...edance.com, longman@...hat.com,
	kernel-team@...udflare.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V11] cgroup/rstat: Avoid flushing if there is an ongoing
 root flush

Hi Jesper,

kernel test robot noticed the following build errors:

[auto build test ERROR on tj-cgroup/for-next]
[also build test ERROR on axboe-block/for-next linus/master v6.11-rc7]
[cannot apply to akpm-mm/mm-everything next-20240913]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jesper-Dangaard-Brouer/cgroup-rstat-Avoid-flushing-if-there-is-an-ongoing-root-flush/20240913-010800
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
patch link:    https://lore.kernel.org/r/172616070094.2055617.17676042522679701515.stgit%40firesoul
patch subject: [PATCH V11] cgroup/rstat: Avoid flushing if there is an ongoing root flush
config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20240914/202409140533.2vt8QPj8-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240914/202409140533.2vt8QPj8-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@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409140533.2vt8QPj8-lkp@intel.com/

All errors (new ones prefixed by >>):

>> mm/vmscan.c:2265:2: error: call to undeclared function 'mem_cgroup_flush_stats_relaxed'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2265 |         mem_cgroup_flush_stats_relaxed(sc->target_mem_cgroup);
         |         ^
   mm/vmscan.c:2265:2: note: did you mean 'mem_cgroup_flush_stats_ratelimited'?
   include/linux/memcontrol.h:1429:20: note: 'mem_cgroup_flush_stats_ratelimited' declared here
    1429 | static inline void mem_cgroup_flush_stats_ratelimited(struct mem_cgroup *memcg)
         |                    ^
   1 error generated.


vim +/mem_cgroup_flush_stats_relaxed +2265 mm/vmscan.c

  2250	
  2251	static void prepare_scan_control(pg_data_t *pgdat, struct scan_control *sc)
  2252	{
  2253		unsigned long file;
  2254		struct lruvec *target_lruvec;
  2255	
  2256		if (lru_gen_enabled())
  2257			return;
  2258	
  2259		target_lruvec = mem_cgroup_lruvec(sc->target_mem_cgroup, pgdat);
  2260	
  2261		/*
  2262		 * Flush the memory cgroup stats, so that we read accurate per-memcg
  2263		 * lruvec stats for heuristics.
  2264		 */
> 2265		mem_cgroup_flush_stats_relaxed(sc->target_mem_cgroup);
  2266	
  2267		/*
  2268		 * Determine the scan balance between anon and file LRUs.
  2269		 */
  2270		spin_lock_irq(&target_lruvec->lru_lock);
  2271		sc->anon_cost = target_lruvec->anon_cost;
  2272		sc->file_cost = target_lruvec->file_cost;
  2273		spin_unlock_irq(&target_lruvec->lru_lock);
  2274	
  2275		/*
  2276		 * Target desirable inactive:active list ratios for the anon
  2277		 * and file LRU lists.
  2278		 */
  2279		if (!sc->force_deactivate) {
  2280			unsigned long refaults;
  2281	
  2282			/*
  2283			 * When refaults are being observed, it means a new
  2284			 * workingset is being established. Deactivate to get
  2285			 * rid of any stale active pages quickly.
  2286			 */
  2287			refaults = lruvec_page_state(target_lruvec,
  2288					WORKINGSET_ACTIVATE_ANON);
  2289			if (refaults != target_lruvec->refaults[WORKINGSET_ANON] ||
  2290				inactive_is_low(target_lruvec, LRU_INACTIVE_ANON))
  2291				sc->may_deactivate |= DEACTIVATE_ANON;
  2292			else
  2293				sc->may_deactivate &= ~DEACTIVATE_ANON;
  2294	
  2295			refaults = lruvec_page_state(target_lruvec,
  2296					WORKINGSET_ACTIVATE_FILE);
  2297			if (refaults != target_lruvec->refaults[WORKINGSET_FILE] ||
  2298			    inactive_is_low(target_lruvec, LRU_INACTIVE_FILE))
  2299				sc->may_deactivate |= DEACTIVATE_FILE;
  2300			else
  2301				sc->may_deactivate &= ~DEACTIVATE_FILE;
  2302		} else
  2303			sc->may_deactivate = DEACTIVATE_ANON | DEACTIVATE_FILE;
  2304	
  2305		/*
  2306		 * If we have plenty of inactive file pages that aren't
  2307		 * thrashing, try to reclaim those first before touching
  2308		 * anonymous pages.
  2309		 */
  2310		file = lruvec_page_state(target_lruvec, NR_INACTIVE_FILE);
  2311		if (file >> sc->priority && !(sc->may_deactivate & DEACTIVATE_FILE) &&
  2312		    !sc->no_cache_trim_mode)
  2313			sc->cache_trim_mode = 1;
  2314		else
  2315			sc->cache_trim_mode = 0;
  2316	
  2317		/*
  2318		 * Prevent the reclaimer from falling into the cache trap: as
  2319		 * cache pages start out inactive, every cache fault will tip
  2320		 * the scan balance towards the file LRU.  And as the file LRU
  2321		 * shrinks, so does the window for rotation from references.
  2322		 * This means we have a runaway feedback loop where a tiny
  2323		 * thrashing file LRU becomes infinitely more attractive than
  2324		 * anon pages.  Try to detect this based on file LRU size.
  2325		 */
  2326		if (!cgroup_reclaim(sc)) {
  2327			unsigned long total_high_wmark = 0;
  2328			unsigned long free, anon;
  2329			int z;
  2330	
  2331			free = sum_zone_node_page_state(pgdat->node_id, NR_FREE_PAGES);
  2332			file = node_page_state(pgdat, NR_ACTIVE_FILE) +
  2333				   node_page_state(pgdat, NR_INACTIVE_FILE);
  2334	
  2335			for (z = 0; z < MAX_NR_ZONES; z++) {
  2336				struct zone *zone = &pgdat->node_zones[z];
  2337	
  2338				if (!managed_zone(zone))
  2339					continue;
  2340	
  2341				total_high_wmark += high_wmark_pages(zone);
  2342			}
  2343	
  2344			/*
  2345			 * Consider anon: if that's low too, this isn't a
  2346			 * runaway file reclaim problem, but rather just
  2347			 * extreme pressure. Reclaim as per usual then.
  2348			 */
  2349			anon = node_page_state(pgdat, NR_INACTIVE_ANON);
  2350	
  2351			sc->file_is_tiny =
  2352				file + free <= total_high_wmark &&
  2353				!(sc->may_deactivate & DEACTIVATE_ANON) &&
  2354				anon >> sc->priority;
  2355		}
  2356	}
  2357	

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ