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 37A7ACDB482 for ; Thu, 12 Oct 2023 12:23:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A25DD8D0125; Thu, 12 Oct 2023 08:23:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D5508D0002; Thu, 12 Oct 2023 08:23:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C5308D0125; Thu, 12 Oct 2023 08:23:17 -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 7E3128D0002 for ; Thu, 12 Oct 2023 08:23:17 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 40AAA1205DD for ; Thu, 12 Oct 2023 12:23:17 +0000 (UTC) X-FDA: 81336724434.14.CA4C64A Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf19.hostedemail.com (Postfix) with ESMTP id 202791A000F for ; Thu, 12 Oct 2023 12:23:14 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HXJ7UUh5; spf=pass (imf19.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697113395; 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=fazQ2jRilRHFDfeS55HmBgMuXEdvgAKYlO85LuHtR/s=; b=je+RsqgJRN/ZkWWqJgFhsP4os9gNmX5kmEi9hF9QlAO2xFKUAgW6yAt0Uy8G8kPosOVW/0 2UsT3tqK5+yOYg5/OM6rUmCBe4x1cxP2rzOaaYpW2Qyh4ActNTZl8qJi/h5Bnme2qdqjOC UkB3TddMJ73g05i8VDNMN0cB+FuQUn4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697113395; a=rsa-sha256; cv=none; b=L4AEq7LL4lBw6pB8DOLfUu5Cp8gwc+ehZTJd5pH0FbjxmoykxON1r73W3o4RxQPYefiPRw W7yY5NwY0B9logqR2NOqjX+Xo3wwhUbnCW2OwLeHyU92rNTkhYrGRXC1EV7jqkBMHrYTsN bZzy9kY2Lkgd6oK78kmrLvRlLUOx27c= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HXJ7UUh5; spf=pass (imf19.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697113395; x=1728649395; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=7uKE27R2y/wLv51v6eEem7rTHjDlCCUWdaUVwm5Xme4=; b=HXJ7UUh5szrjjvtZtTINk5gdDnXNPJyKkpgVPRcl7R8yqz6WCyJDv5ur 4SdPlP6ejF2ml/c4Cam/vyKF+Q3zWk3eAPQABZGo9SLUNU9x1ZE0X3cCR /xR8yMAuLVbRdu68vKTlyvF+z1A8EnVB6WIxnduuU1gfDgfusN4IKjl/N hCKcTPwZH6w+MBbEMy9HiQ2YS2eE5eSi034AbtysFyzt8r1nUrYgCL04q azsIGyrBHPpQAGr1ex6uFsTUm4Z7reActws/DaV8aOLgaQqaqCBhyzmxw kQ6+5LBKFvLYB7g6xOc3E8m9RQoyfnmmk69jQRCw50gmh7Y8lKR8Opj2x g==; X-IronPort-AV: E=McAfee;i="6600,9927,10861"; a="369972090" X-IronPort-AV: E=Sophos;i="6.03,218,1694761200"; d="scan'208";a="369972090" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2023 05:23:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10861"; a="754226968" X-IronPort-AV: E=Sophos;i="6.03,218,1694761200"; d="scan'208";a="754226968" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2023 05:23:10 -0700 From: "Huang, Ying" To: Mel Gorman Cc: , , Arjan Van De Ven , Andrew Morton , Vlastimil Babka , David Hildenbrand , Johannes Weiner , Dave Hansen , Michal Hocko , Pavel Tatashin , Matthew Wilcox , "Christoph Lameter" Subject: Re: [PATCH 01/10] mm, pcp: avoid to drain PCP when process exit References: <20230920061856.257597-1-ying.huang@intel.com> <20230920061856.257597-2-ying.huang@intel.com> <20231011124610.4punxroovolyvmgr@techsingularity.net> Date: Thu, 12 Oct 2023 20:21:06 +0800 In-Reply-To: <20231011124610.4punxroovolyvmgr@techsingularity.net> (Mel Gorman's message of "Wed, 11 Oct 2023 13:46:10 +0100") Message-ID: <87zg0odob1.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: yn579shibi4qdkyynq11rjcfr5bow4t7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 202791A000F X-Rspam-User: X-HE-Tag: 1697113394-994095 X-HE-Meta: U2FsdGVkX18hnz07LceI5bGu5WKChY+C7LSwzC//lLYJRF4fUP5zFwAglpWGcSWjrZ5v7Tf7da9HmHUTIvrFxjXtyeBbotC5tW1ZvbaB7J011BTlxqX/t7DAWQ9Em6JaV+oCv4dqF7VJvKXkccgeL1R2GTa7DuTs0m3PXajevL0pbjs47jDADO0eKKrGTNiwqzbvwdNX+39gfibkKOzvO3RWcHxiWWWkaO+P98NYR26uH6OCqs9JipSqWkJLW4w+iVR0jLLHUA+/g5g0DhxSnSkYYpGwKHy3JdBoxFXHDEppVe4k+d0ns644lD0nofRpDU5+1X5S5uCQWOuWc0H7q5P254yOqJ48NSPdcAzGJ5nDQI4qz45cS9rlc8oUeCuYd2SMd7R4CxKFG2aHebSBAG47CYW/CmEomQIzFdQiUBZ6dJ+4GSfRHTIZ0fH8hzfx7QldPMGpkTEtIkPnkBcgimxM1nZgXZ4ZkPS8zLTGE1JEYxEgDnOBvCBR7GJcOqSJXZMqoHr+Lg7MXZ15PVBPSFUg2KQpftsE2KlWqcvSHvjZ+LtuJYzXVGo2lsD0z9px12zp7fSPrwKTmgeoB01pjvEbOcLa1ACbrzr3lwTmhXh+cSGxgNKtZntCdTEuZ54Gv02oqexzG6ntm7Sk0eFjZmiBaDbb2B0WI5uH7Z7qFHiBo6IAaP3psR4lo2vPy5tOYSsIXllXfHdg1JU1r6rFu1Rx9a1fFRQ25FGkTd67Mez4EWmqvcVA5zpUimcYCTFsRyjUXBq6TTARPw2nbmFzoiYnS7ZwGiZtlt9ms9bpCugTlFbFcK+W/fSVDbB7739Y0ALfMHhqaArPOXgkFdfDYPO3cZ7oJ9yzIOk2c38C+f72jeAj6zUFKxapIUDoh9CZz+oelq207o5D9Mggsu9lWSV4sA0ZMY0bp1egSxwTgpgKdiMfFn6Ijb7pPg48oXUehjpekFLJZ8imIGQSepH DcQmexuh RSld0vP7XXHlox6HtO5xXb4Zqt0lo64u7HTqIH22gtvznFK6C0EXVp1ULkL1jvoxPBjANH2FmnsoX61reWxocLSULvOUuVa++BTbxEevGN0eOmm9Vb1H/9TFNY4Ygju9QIF4awtr1xDbHR2YoRFm3gcY4g1b2kEQ3ukdv04f9iLybDdDaXcllTNwvMGwFDjUD7w5vYnsLnK4idNiKNXZGriad2jbXSM6BziJ+vT2Cq/Y7AP4= 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: Mel Gorman writes: > On Wed, Sep 20, 2023 at 02:18:47PM +0800, Huang Ying wrote: >> In commit f26b3fa04611 ("mm/page_alloc: limit number of high-order >> pages on PCP during bulk free"), the PCP (Per-CPU Pageset) will be >> drained when PCP is mostly used for high-order pages freeing to >> improve the cache-hot pages reusing between page allocation and >> freeing CPUs. >> >> But, the PCP draining mechanism may be triggered unexpectedly when >> process exits. With some customized trace point, it was found that >> PCP draining (free_high == true) was triggered with the order-1 page >> freeing with the following call stack, >> >> => free_unref_page_commit >> => free_unref_page >> => __mmdrop >> => exit_mm >> => do_exit >> => do_group_exit >> => __x64_sys_exit_group >> => do_syscall_64 >> >> Checking the source code, this is the page table PGD >> freeing (mm_free_pgd()). It's a order-1 page freeing if >> CONFIG_PAGE_TABLE_ISOLATION=y. Which is a common configuration for >> security. >> >> Just before that, page freeing with the following call stack was >> found, >> >> => free_unref_page_commit >> => free_unref_page_list >> => release_pages >> => tlb_batch_pages_flush >> => tlb_finish_mmu >> => exit_mmap >> => __mmput >> => exit_mm >> => do_exit >> => do_group_exit >> => __x64_sys_exit_group >> => do_syscall_64 >> >> So, when a process exits, >> >> - a large number of user pages of the process will be freed without >> page allocation, it's highly possible that pcp->free_factor becomes >> > 0. >> >> - after freeing all user pages, the PGD will be freed, which is a >> order-1 page freeing, PCP will be drained. >> >> All in all, when a process exits, it's high possible that the PCP will >> be drained. This is an unexpected behavior. >> >> To avoid this, in the patch, the PCP draining will only be triggered >> for 2 consecutive high-order page freeing. >> >> On a 2-socket Intel server with 224 logical CPU, we tested kbuild on >> one socket with `make -j 112`. With the patch, the build time >> decreases 3.4% (from 206s to 199s). The cycles% of the spinlock >> contention (mostly for zone lock) decreases from 43.6% to 40.3% (with >> PCP size == 361). The number of PCP draining for high order pages >> freeing (free_high) decreases 50.8%. >> >> This helps network workload too for reduced zone lock contention. On >> a 2-socket Intel server with 128 logical CPU, with the patch, the >> network bandwidth of the UNIX (AF_UNIX) test case of lmbench test >> suite with 16-pair processes increase 17.1%. The cycles% of the >> spinlock contention (mostly for zone lock) decreases from 50.0% to >> 45.8%. The number of PCP draining for high order pages >> freeing (free_high) decreases 27.4%. The cache miss rate keeps 0.3%. >> >> Signed-off-by: "Huang, Ying" > > Acked-by: Mel Gorman > > However, I want to note that batching on exit is not necessarily > unexpected. For processes that are multi-TB in size, the time to exit > can actually be quite large and batching is of benefit but optimising > for exit is rarely a winning strategy. The pattern of "all allocs on CPU > B and all frees on CPU B" or "short-lived tasks triggering a premature > drain" is a bit more compelling but not worth a changelog rewrite. >> >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >> index 4106fbc5b4b3..64d5ed2bb724 100644 >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -676,12 +676,15 @@ enum zone_watermarks { >> #define high_wmark_pages(z) (z->_watermark[WMARK_HIGH] + z->watermark_boost) >> #define wmark_pages(z, i) (z->_watermark[i] + z->watermark_boost) >> >> +#define PCPF_PREV_FREE_HIGH_ORDER 0x01 >> + > > The meaning of the flag and its intent should have been documented. Sure. Will add comments for the flags. -- Best Regards, Huang, Ying