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 04D5CC001DE for ; Mon, 17 Jul 2023 08:21:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3912A6B0072; Mon, 17 Jul 2023 04:21:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 319F08D0002; Mon, 17 Jul 2023 04:21:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BA018D0001; Mon, 17 Jul 2023 04:21:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 071006B0072 for ; Mon, 17 Jul 2023 04:21:03 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D08D21A0412 for ; Mon, 17 Jul 2023 08:21:02 +0000 (UTC) X-FDA: 81020408364.23.578D5B2 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf08.hostedemail.com (Postfix) with ESMTP id 91B9C160005 for ; Mon, 17 Jul 2023 08:20:59 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=N5emRCts; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf08.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689582060; 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=2o4373jD05NVNFJ4F9qrKxo5v5H39cUYqM490ipjKzU=; b=4ouz6Z64R0s/AMvzgLXCLmAauIkTKvQRRhZOFA4ZFpLCSrXzp7G/hgTHLiXt9fgdx1Jz+z th7OnOTKtVhg6EAYEDFFr1Vid9Qned3MJhtX5m+/Bts+7xArQRhVVk0ZaOqvYEcWaefJCN tV8zUkMnjhjcLaY8fehjHt5V03ey3Jk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=N5emRCts; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf08.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689582060; a=rsa-sha256; cv=none; b=I+78j3G8InUY3siSBtJpoVgi/0CLR1zQmGDHD8BSGdxipMosu4X+MVgiApQBqfO+d8D6ci sqh3fqxYIEgKzTpoyBdaDPT/egF4q3+qqZPvy70Sz0SgEJDKm//aGqoe030Y8T/7Is3vz1 r28+h9nOVYlZdnFYdFmtE2o6pZkHVo8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689582059; x=1721118059; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=EXOX2k9VFsuPowKXuZz03YoTvqXpHZ/inazra+32p+s=; b=N5emRCtsVldXmWN2Y8dHtim7JgimYZ5TVDpVndgQcMHWNXV1/1TIgXPZ AMB5WgbKRdeLai3fGi0pwMmUIs56mtQeQjkvtU7XXjKGh/Gxca7jyr+4r Xa/QXIuBjt5itjvztiZ7/0zqxV30OJouQvfELvfj4/o0s4N2WfIGbqTlu hJe0s6KLEifxtHyP3ovcLKSoyXuD9cW8q3g0NluaP37asoAsAgeil93f5 PWA73Zcg/A/WmkVIOlQSqaTRI/Z0hOlloGQWthEdNgpbJHuZ2JbCK6TDx FYq3219KQ6Ti1tM6ilXyBRU0FnFV0yWwhC4MUch6+Y/Gl5P7AZWVaNktZ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10773"; a="364748645" X-IronPort-AV: E=Sophos;i="6.01,211,1684825200"; d="scan'208";a="364748645" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2023 01:20:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10773"; a="758322066" X-IronPort-AV: E=Sophos;i="6.01,211,1684825200"; d="scan'208";a="758322066" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2023 01:20:54 -0700 From: "Huang, Ying" To: Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Arjan Van De Ven , Andrew Morton , Mel Gorman , Vlastimil Babka , David Hildenbrand , Johannes Weiner , Dave Hansen , Pavel Tatashin , Matthew Wilcox Subject: Re: [RFC 1/2] mm: add framework for PCP high auto-tuning References: <20230710065325.290366-1-ying.huang@intel.com> <20230710065325.290366-2-ying.huang@intel.com> <87edldefnt.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 17 Jul 2023 16:19:12 +0800 In-Reply-To: (Michal Hocko's message of "Fri, 14 Jul 2023 10:59:19 +0200") Message-ID: <87wmyzc5mn.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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 91B9C160005 X-Stat-Signature: mnzmzwwupxjwzbg9ikkpbat396tb697k X-HE-Tag: 1689582059-575126 X-HE-Meta: U2FsdGVkX1+J1StReL8a9xHTRcdfBijV7HoAMwJvImjVdnI/Q0y+IjB0AaoKaS3O7FltLGvm9lH8tl7H5MWv2fFK8XpCh0MGQzO/TX2Nt84QEIS34dqmvZEV4R1OB2aIxIpDf+yn3I1oQFaerGZIqHSXaPNOl88ZO1eid6eoZY6A84eVfJlxkSE6TC3H1F60tpbtZy3CoMhmRU82UK+wbZLi8Nt+4kmuE/+PXBjR2vAbqnwZf47jY9Dru+JF48UPUh8DiyqER7rlriSCHySuL0THVgmit+vXGmgJ0aVn0wW+ydV7UG7wO73YmQpU53hKjkuQrzRMs9uP4Tud6cMRKsl5JRXMUxBjcru916Z3wJMgG/jVd+W6wPMCtQkeFHjFn/tgZqxByrvxesk+cOsgB1+vHtqWd+7VEHXFjTgUg1t/uBMw2fW1aT/vEMgqDv0ENoYmeiafRKbicmznIC+iumIf2aRmL13zWF9znHthxW5VJyHBDilyPi+2Gpk/XEz7lQOVp8RfbixSlYY9IStPwDa8sttx+xOaKZLlhtg1SMmffaTykRchl7VJ5xJiZJP1wQjgIYkf3RXkUrcriKFazIpSRpRMp9qn9ERPhmHObviqn+NG4EvNvtMiFYpNKk64c+0SnKtr9fKd36cH6u1jxvqtXVlnG8QqSAoWTTB1mq33TmozkizCrOpiL9XKgI6JYNX0WwVpbJ4X8QeD3pScBEotbFI4rC1p1e+CX/4G71HxA/bMl7P1QaRKObL+KdI+ldBKjmWLKFvv2I0Ipu/vh4Ot4MrWDkYR5R+wN5PG1DVyGeK3oDyQjz+zo28U+zs/TmPx+hLLkXzENBcmu5Cg0rhkV/SK83Ulnw9JruYHfQtvSccgb2vSEB182wQ+ZnsGC5m7SXnQcdcbyIxxocx/yom8foTf6QKVlCmO+2df5xIB77WyBImx3w4DG+b2mIdqteBVOIN8/3+YjeujxUg rhVRCNaa gR/jZiX3uNklMDsns4DJ1k5WcIDrjpEIkUA7YlKtGO5QQunBsgslQ9JmzA18Vxpk6L7sHCvbnu7CqqUY81vv+yJLPxwtFdVi6HvMbi9EsvjKSHhyeVSIPEOgkAKjLokJZswBk1EaKwWUDazoyF+sxOwBBk9HxzyiQ86B/pu31oPzxVInfuUrJkE0s//Tka4I8ALrYSepAiC7r/3A= 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: Michal Hocko writes: > On Wed 12-07-23 15:45:58, Huang, Ying wrote: >> Michal Hocko writes: >> >> > On Mon 10-07-23 14:53:24, Huang Ying wrote: >> >> The page allocation performance requirements of different workloads >> >> are usually different. So, we often need to tune PCP (per-CPU >> >> pageset) high to optimize the workload page allocation performance. >> >> Now, we have a system wide sysctl knob (percpu_pagelist_high_fraction) >> >> to tune PCP high by hand. But, it's hard to find out the best value >> >> by hand. And one global configuration may not work best for the >> >> different workloads that run on the same system. One solution to >> >> these issues is to tune PCP high of each CPU automatically. >> >> >> >> This patch adds the framework for PCP high auto-tuning. With it, >> >> pcp->high will be changed automatically by tuning algorithm at >> >> runtime. Its default value (pcp->high_def) is the original PCP high >> >> value calculated based on low watermark pages or >> >> percpu_pagelist_high_fraction sysctl knob. To avoid putting too many >> >> pages in PCP, the original limit of percpu_pagelist_high_fraction >> >> sysctl knob, MIN_PERCPU_PAGELIST_HIGH_FRACTION, is used to calculate >> >> the max PCP high value (pcp->high_max). >> > >> > It would have been very helpful to describe the basic entry points to >> > the auto-tuning. AFAICS the central place of the tuning is tune_pcp_high >> > which is called from the freeing path. Why? Is this really a good place >> > considering this is a hot path? What about the allocation path? Isn't >> > that a good spot to watch for the allocation demand? >> >> Yes. The main entry point to the auto-tuning is tune_pcp_high(). Which >> is called from the freeing path because pcp->high is only used by page >> freeing. It's possible to call it in allocation path instead. The >> drawback is that the pcp->high may be updated a little later in some >> situations. For example, if there are many page freeing but no page >> allocation for quite long time. But I don't think this is a serious >> problem. > > I consider it a serious flaw in the framework as it cannot cope with the > transition of the allocation pattern (e.g. increasing the allocation > pressure). Sorry, my previous words are misleading. What I really wanted to say is that the problem may be just theoretical. Anyway, I will try to avoid this problem in the future version. >> > Also this framework seems to be enabled by default. Is this really >> > desirable? What about workloads tuning the pcp batch size manually? >> > Shouldn't they override any auto-tuning? >> >> In the current implementation, the pcp->high will be tuned between >> original pcp high (default or tuned manually) and the max pcp high (via >> MIN_PERCPU_PAGELIST_HIGH_FRACTION). So the high value tuned manually is >> respected at some degree. >> >> So you think that it's better to disable auto-tuning if PCP high is >> tuned manually? > > Yes, I think this is a much safer option. For two reasons 1) it is less > surprising to setups which know what they are doing by configuring the > batching and 2) the auto-tuning needs a way to get disabled in case > there are pathological patterns in behavior. OK. Best Regards, Huang, Ying