From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E1A6E7D0A1 for ; Thu, 21 Sep 2023 23:30:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C586F6B027C; Thu, 21 Sep 2023 19:30:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C08DA6B027D; Thu, 21 Sep 2023 19:30:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAA446B027E; Thu, 21 Sep 2023 19:30:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9C1196B027C for ; Thu, 21 Sep 2023 19:30:23 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6B737C0940 for ; Thu, 21 Sep 2023 23:30:23 +0000 (UTC) X-FDA: 81262200726.12.D2BCA6F Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by imf04.hostedemail.com (Postfix) with ESMTP id B994A40016 for ; Thu, 21 Sep 2023 23:30:20 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HOQd23km; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf04.hostedemail.com: domain of lkp@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=lkp@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695339021; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PbLZLRFryLgNnZtoUZ0lbULYpAU4KGeIcP5RKB6GDDA=; b=hyGFvyu4Q1IhmBi//LObc52adf7rQS0Wh7KvBDFrj056iFPMjjGJu17MOcUUz08qQGQAhO WZ64NsD1WQkSs1g1fa5QaLp8sQh4YH4rLKolEMAYMqKr2zSU/TXA8QJXe+FOcTIxBzpnNi OaHG9+IcWJbdUGLMBLyL1LVxEwpb0pA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HOQd23km; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf04.hostedemail.com: domain of lkp@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=lkp@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695339021; a=rsa-sha256; cv=none; b=vtl7LhCycmowwAMxBPDrpLf7PLJ1j8pcV35+ZQVXQaNnSn0hZtMjMKBrJF34Ian1S2VT/8 qkwTWJn491G65MK0eva01lY9QpfR2f7DohXDQlyLQuZcXhkFSY+bZNKL/HgHLLhg8+31FH Eulhchypg1+WgPryGxFpugHWW6CEYUE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695339020; x=1726875020; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1ME8C2bw+S9S5r4SeJgGmarGxYaSLP1dZzXZxGZxMzo=; b=HOQd23kmgWc82yqToryFdtSkHmu8OeCB539jR+9MzqHmZiVEaWWAF9TO XJVQdoUPnvSDwvTg5YugoAkdfm+W4Hkx1AuLLYsRzh9me3PLTBt3vqkyu AR/KOtlIvVGOt9jb68TeT2QBtiX+yYROYXEl9PD5uSYx02Ps3mqSeSRd1 Jv6hSPU1h4m71OYpONHFhfCC7CUVWsOZRinGm1+KtMzqO8rzCJ10BYkTG 81Oa24yOLv5rTfYKJVeheK5tSWRlQFqD3B0/L/SPus/e7bjup5a6diU0H KVCLjJNwDvkZMNA9hKchKaOZzmdJROhrmvac36edqVeEEQWdJfCIVsoat w==; X-IronPort-AV: E=McAfee;i="6600,9927,10840"; a="360076110" X-IronPort-AV: E=Sophos;i="6.03,166,1694761200"; d="scan'208";a="360076110" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2023 16:30:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10840"; a="723960313" X-IronPort-AV: E=Sophos;i="6.03,166,1694761200"; d="scan'208";a="723960313" Received: from lkp-server02.sh.intel.com (HELO b77866e22201) ([10.239.97.151]) by orsmga006.jf.intel.com with ESMTP; 21 Sep 2023 16:30:14 -0700 Received: from kbuild by b77866e22201 with local (Exim 4.96) (envelope-from ) id 1qjT7c-0000Xt-1e; Thu, 21 Sep 2023 23:30:12 +0000 Date: Fri, 22 Sep 2023 07:29:54 +0800 From: kernel test robot To: Yosry Ahmed , Andrew Morton Cc: oe-kbuild-all@lists.linux.dev, Linux Memory Management List , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , Tejun Heo , Michal =?iso-8859-1?Q?Koutn=FD?= , Waiman Long , kernel-team@cloudflare.com, Wei Xu , Greg Thelen , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Yosry Ahmed Subject: Re: [PATCH 4/5] mm: workingset: move the stats flush into workingset_test_recent() Message-ID: <202309220704.NF0GCRP2-lkp@intel.com> References: <20230921081057.3440885-5-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230921081057.3440885-5-yosryahmed@google.com> X-Rspamd-Queue-Id: B994A40016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: e5d7t83pkbuo8nnb7zrxgrskn83awkz9 X-HE-Tag: 1695339020-208853 X-HE-Meta: U2FsdGVkX193ReQRm6TzQnOe9G8S/QXyvK5G7rXA+dCsrlje/0QT4/VMNy4TMqdhphBC571XML15/UOLQYR2qVTCjC9tTAwH8xmCuPLOogcVh34Cqiwe255CSoVZ2CtMDgsiH0yOL/xELpMUA5Kzjr+WbHvuGCY6r2YkhSDgCBGItFESWjR5znJ1UsUfX4PBQ4L0C26DHfKC8YMFx16+2B/YJ4XYkRMDYwrPZd0lZ+YyZXhwOEs0R2HLanUBFDFVOrX4cpGagEgTPJNQae+gR5EHS4R7Xx/pqvTULvAynnJIFCOEyu0X7dqAqg0zcOVMqi/DKkfs1N3+TsoEzpYfidlzT7/Yp9y830m/q9bcaGEABA5839+aqLz3fXdm9awQQGenCyHL7wXO+0Qm5nSD7CeZjHV/Lr/foxHxa+aJdenBOpf6kKDSHArE6sKm9oTlAcdtda8l5Z50KYDQb1M8ei06acd4p7phybQwf42KJgzCkquMfbWK6jxE/lic+okGrlTx6HMzLRH9/G38sFhd5n1QW7xzsX/2Gy3R6vMgOj6Y274rgiO8MCQi4nQ/mLXJo+XG/0lLCsrCCouM3tP+nUIqA2uW1JblJlIqCOOo8Jf31kjGdVO0/G9L4s8Nc6VZHlWlcsYQs+lKcXSta+/KhtT+Qxeo92KLkiYQ1XM52yinIQP5FzGUxaEneuYH0eG1vksR1UqE2/T6bFJvvIWT1Q5DCMbGcAFtZFY+3fNGUN12zdkY0pLsOvomimQXZcbYbcY6urAo7/VdGJX7XUgX700qQnUcX27khDbv0XPArkkqO9JXi7d0iD/yVbpc3kpkGVGQL1RRB68AZR6rDbZkPatwuSqLMrq544domSRvNLQ20KWf7qROUF6q7CNOrTBfZPAsGQmzszHF36J9EEWjD5t9qD8pGfW2kRc8s8OcMYD7TXoPLvOhPaGO0nSDYGYXJ6lXw/RvvpVvIshD4vZ WED1mZlT 24u1lwj0RAJXvIpn/RlZk3eRiS/UqOlHhYjRrJwmvU4lesxOafA9ppK0dl20z4ibheBpXnH5hwq5U9+TdrG85SwcjPfVNdE2GI0uCY7qofTNsDRPTTh3QjH6JShmce590RIcU02iu409pMX/Mx5G0rhbnLtPxtNshCAewkf7H0gX/LiRjzwVd5ww684/AUV2b6Kn796bKmzUBcAN9M8UYPOS8aDAtes6P7ooz88h+L/hVx82CY/jTp1N7z69PKFuCx0bf6NDPt6svHDoZdNfDJNY1vhtQMy6pqCTx7sitAf59ukbVM0aL/zhrOqnx/OQtESchrbkrHuozvn0v1awXm2L1amGMASI5w9T9KTdLfpFXC/9Fn0QTbq80gUUaSaSLj4Ib X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Yosry, 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/Yosry-Ahmed/mm-memcg-change-flush_next_time-to-flush_last_time/20230921-161246 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20230921081057.3440885-5-yosryahmed%40google.com patch subject: [PATCH 4/5] mm: workingset: move the stats flush into workingset_test_recent() config: um-i386_defconfig (https://download.01.org/0day-ci/archive/20230922/202309220704.NF0GCRP2-lkp@intel.com/config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20230922/202309220704.NF0GCRP2-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 | Closes: https://lore.kernel.org/oe-kbuild-all/202309220704.NF0GCRP2-lkp@intel.com/ All errors (new ones prefixed by >>): mm/workingset.c: In function 'workingset_test_recent': >> mm/workingset.c:461:25: error: dereferencing pointer to incomplete type 'struct mem_cgroup' css_get(&eviction_memcg->css); ^~ vim +461 mm/workingset.c 405 406 /** 407 * workingset_test_recent - tests if the shadow entry is for a folio that was 408 * recently evicted. Also fills in @workingset with the value unpacked from 409 * shadow. 410 * @shadow: the shadow entry to be tested. 411 * @file: whether the corresponding folio is from the file lru. 412 * @workingset: where the workingset value unpacked from shadow should 413 * be stored. 414 * 415 * Return: true if the shadow is for a recently evicted folio; false otherwise. 416 */ 417 bool workingset_test_recent(void *shadow, bool file, bool *workingset) 418 { 419 struct mem_cgroup *eviction_memcg; 420 struct lruvec *eviction_lruvec; 421 unsigned long refault_distance; 422 unsigned long workingset_size; 423 unsigned long refault; 424 int memcgid; 425 struct pglist_data *pgdat; 426 unsigned long eviction; 427 428 rcu_read_lock(); 429 430 if (lru_gen_enabled()) { 431 bool recent = lru_gen_test_recent(shadow, file, 432 &eviction_lruvec, &eviction, 433 workingset); 434 rcu_read_unlock(); 435 return recent; 436 } 437 438 unpack_shadow(shadow, &memcgid, &pgdat, &eviction, workingset); 439 eviction <<= bucket_order; 440 441 /* 442 * Look up the memcg associated with the stored ID. It might 443 * have been deleted since the folio's eviction. 444 * 445 * Note that in rare events the ID could have been recycled 446 * for a new cgroup that refaults a shared folio. This is 447 * impossible to tell from the available data. However, this 448 * should be a rare and limited disturbance, and activations 449 * are always speculative anyway. Ultimately, it's the aging 450 * algorithm's job to shake out the minimum access frequency 451 * for the active cache. 452 * 453 * XXX: On !CONFIG_MEMCG, this will always return NULL; it 454 * would be better if the root_mem_cgroup existed in all 455 * configurations instead. 456 */ 457 eviction_memcg = mem_cgroup_from_id(memcgid); 458 if (!mem_cgroup_disabled() && !eviction_memcg) 459 return false; 460 > 461 css_get(&eviction_memcg->css); 462 rcu_read_unlock(); 463 464 /* Flush stats (and potentially sleep) outside the RCU read section */ 465 mem_cgroup_flush_stats_ratelimited(); 466 467 eviction_lruvec = mem_cgroup_lruvec(eviction_memcg, pgdat); 468 refault = atomic_long_read(&eviction_lruvec->nonresident_age); 469 470 /* 471 * Calculate the refault distance 472 * 473 * The unsigned subtraction here gives an accurate distance 474 * across nonresident_age overflows in most cases. There is a 475 * special case: usually, shadow entries have a short lifetime 476 * and are either refaulted or reclaimed along with the inode 477 * before they get too old. But it is not impossible for the 478 * nonresident_age to lap a shadow entry in the field, which 479 * can then result in a false small refault distance, leading 480 * to a false activation should this old entry actually 481 * refault again. However, earlier kernels used to deactivate 482 * unconditionally with *every* reclaim invocation for the 483 * longest time, so the occasional inappropriate activation 484 * leading to pressure on the active list is not a problem. 485 */ 486 refault_distance = (refault - eviction) & EVICTION_MASK; 487 488 /* 489 * Compare the distance to the existing workingset size. We 490 * don't activate pages that couldn't stay resident even if 491 * all the memory was available to the workingset. Whether 492 * workingset competition needs to consider anon or not depends 493 * on having free swap space. 494 */ 495 workingset_size = lruvec_page_state(eviction_lruvec, NR_ACTIVE_FILE); 496 if (!file) { 497 workingset_size += lruvec_page_state(eviction_lruvec, 498 NR_INACTIVE_FILE); 499 } 500 if (mem_cgroup_get_nr_swap_pages(eviction_memcg) > 0) { 501 workingset_size += lruvec_page_state(eviction_lruvec, 502 NR_ACTIVE_ANON); 503 if (file) { 504 workingset_size += lruvec_page_state(eviction_lruvec, 505 NR_INACTIVE_ANON); 506 } 507 } 508 509 mem_cgroup_put(eviction_memcg); 510 return refault_distance <= workingset_size; 511 } 512 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki