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 BCE7FC3DA47 for ; Thu, 11 Jul 2024 08:20:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3270A6B0096; Thu, 11 Jul 2024 04:20:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D6F66B0098; Thu, 11 Jul 2024 04:20:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A02E6B0099; Thu, 11 Jul 2024 04:20:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EF9046B0096 for ; Thu, 11 Jul 2024 04:20:19 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 62DD98045C for ; Thu, 11 Jul 2024 08:20:19 +0000 (UTC) X-FDA: 82326774558.27.5B75613 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf06.hostedemail.com (Postfix) with ESMTP id 5C78518001E for ; Thu, 11 Jul 2024 08:20:16 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=f6hkIWmR; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720685993; a=rsa-sha256; cv=none; b=NmT/M6eNUozJy+4TfvUEcCeejMlKQ/ibDL5UHCUFz02QLlxcopYePOsfjv7slOz8wxxlzG 02CDXyP0+bwb+E91Nuz15gAL6dnK5h8pnQueS7qJgn619hp58POYTm4YkVRdVGjS9vZC2X 7c1HrfTzB2rJGj2IGfGVzTIrw+zcbOc= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=f6hkIWmR; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.9 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=1720685993; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Q+rZQqKuvrl12E8udaJ4T0IQsafjCY5nl0CG1FAh2Fc=; b=o5BbRc9OjwSXtJvaErM3lHTar7NgSOcWIJ/pVGsEoFXlHxoLSerSzllod3sFO/txnPn1m4 Z00XdYltgt00iIqxWBmn01N65aLfArhkPpPa9+N8J2R6bJlW+HAHJxLbB//FKmVnvicCXS jtG47nTLUHLJ0KT+nmvdbOAUyTmFv40= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1720686016; x=1752222016; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=ruI/cRkfAGx2H17lStfrcaEgoOlKadk7Vozz0EiBz+Y=; b=f6hkIWmRy5sLrU3HYK0Wahv+9Tw9Om+MAvpm4y94GjF8hXg7DJOYwpoc Wvgd3NnZBEoIcmSCvgoilNU9BYYyLPRi/4M+PqEf3vMTWn8WSQj/NP/CI GBlBLrZZnA5Ni84iJ3GmrKwfjoJ48XcbsZEe7JoDyP+WHvNEgxUXoZOJp lOSlcfteOG5whqqwLVfZs9pd6sJCA9v7/Zs2yNPlDsujTKEDtnlV9ARGJ Z9fpr6JDhVjVKxi37q+WQbTr6wFwjfBS/PVwJI5fjKfHwqlQTIUCpKrug KmrrxTMY5OX+LvwtbPm6P8kbAeLIdkPmr0nRJoE5X2lOVEIaBmRkAGvkr g==; X-CSE-ConnectionGUID: 2horsIFPR0G1Epgpzt6wnA== X-CSE-MsgGUID: k9BM483QQ66SzUbAqjKHcA== X-IronPort-AV: E=McAfee;i="6700,10204,11129"; a="28714218" X-IronPort-AV: E=Sophos;i="6.09,199,1716274800"; d="scan'208";a="28714218" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jul 2024 01:20:15 -0700 X-CSE-ConnectionGUID: 86D+maDLQ9at+GLqf32tQw== X-CSE-MsgGUID: d9PE/P0RTQi3M0lBv7mZKA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,199,1716274800"; d="scan'208";a="53656168" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jul 2024 01:20:13 -0700 From: "Huang, Ying" To: Yafang Shao Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, linux-mm@kvack.org, Matthew Wilcox , David Rientjes Subject: Re: [PATCH 3/3] mm/page_alloc: Introduce a new sysctl knob vm.pcp_batch_scale_max In-Reply-To: (Yafang Shao's message of "Thu, 11 Jul 2024 15:25:34 +0800") References: <20240707094956.94654-1-laoar.shao@gmail.com> <20240707094956.94654-4-laoar.shao@gmail.com> <878qyaarm6.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o774a0pv.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Thu, 11 Jul 2024 16:18:21 +0800 Message-ID: <87frsg9waa.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5C78518001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: x3tujtn143hy3ujosfkch5q4q1odtajf X-HE-Tag: 1720686016-526303 X-HE-Meta: U2FsdGVkX19GuRt7IJGBx4sLoyVETMA8VqCLAAYlAYzAwC1PR3v/IqCzxuC0dqNXmW6bsnFOmpXz0mLZuMeBUIrJLt2ZnUgcua4IlKK1dCXUT8SfR+Pz7n4t2DSI93Cs8NUo+Qqjv7Tk5Hih0/Y4X80qhKoX30dnhT5U2Oj438aA0kpjv15Het6vtR8h9+RJ2RNnwbHo0EVycxo4CglVz8vMx/ApeHCJYn356RNZzagwJy85Ip27ep7GnSDUpTf6XBNa19n7f8jl0QXlBeNaLcu6XyyGTjWR72Cio5m/BNEf5LdRkTLQHERUccRn5e+c8O92HLGNw5xS/Y5CnRFUhu+p1iPKz+xQBN9+LMEcwbGGW5uBzbqiKTLgsmDzk+jJt0SY6ueQTL73dQL4sLySVXbKkpntU9mD9ZSWlU7d6Gq2TskhcZFELvd3xTLSXH6I8Hic61thMxDxa9cMotfsTGpq2eEoOXqauUgDCEggHo4pwSiYdUgXvpMGjD76IVzJfdPEjFJqb4c89RndCtgKC/VCXeRxLCT5XJAQPkzyK+qu258k7/CUJqmMhq+Qy622xBc+InrNAJKpaR1fXnCn2Yv7Pe+9uPemc63H/yP/uCidUBNVLVvj+ebzBWCejkZNQT2Ad0O8lSsdxM4APoJYWDXopbWMrh4iU0L4Jh9oH4ybR/qbrTYlancBCWw4BBrxiEpVfxJcKXjqm8WoUDaN8g/+T0kgRIf4i9NmgSRQfeUZiZtbEUiO/dqDhuvkxDzFLtGUlk3e5/n5uOStSy2Ly76TFvUdxmkBQIcKbx+Cv8iSFUcduI5XD6M0N3wM1r9qD+Fnc8+/jALsLI+lxQ0OiivF3z7/fmlAUuaCWsYybtGw6ReHlKlTLsCw5IZtBXfgCJjB+bMyMM5JXPQEturP1KdoRGSPT0WRypZFLHaSBfLtFTsTm5yp7SPhwY9NGMUZ6XowCQW/7fvsZAiRdgm oRXqnuHs lWVaG8a9pK37BEX+V3MnEOdiHwfzdi8g0+wpiuAYzyEaC2+mAE932uNAJJsSvqx1OMDhWEcg5Guk1EBUFcBTl/IjPHdDlwwguxrcgOKBTPyAXq3ZKlM2vtlmN74puQ9dM73jV/6uVXfmRfjHvBWmwj56959R4BonFtDZRJt2EkXOVimBpj+bKIkf/BaYFGD5r4FrDtxgRz1VxcWfnVbfDTSFgIqhdefW08jdOcLk4eBuatnAmFFPLQa261ipW8HvW0Af5B03ADfoTpr+2yN7jzh3tuexKeF7Rma5nv4MtZaxNN309fRTiVRIigg== 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: List-Subscribe: List-Unsubscribe: Yafang Shao writes: > On Thu, Jul 11, 2024 at 2:44=E2=80=AFPM Huang, Ying wrote: >> >> Yafang Shao writes: >> >> > On Wed, Jul 10, 2024 at 10:51=E2=80=AFAM Huang, Ying wrote: >> >> >> >> Yafang Shao writes: >> >> >> >> > The configuration parameter PCP_BATCH_SCALE_MAX poses challenges for >> >> > quickly experimenting with specific workloads in a production envir= onment, >> >> > particularly when monitoring latency spikes caused by contention on= the >> >> > zone->lock. To address this, a new sysctl parameter vm.pcp_batch_sc= ale_max >> >> > is introduced as a more practical alternative. >> >> >> >> In general, I'm neutral to the change. I can understand that kernel >> >> configuration isn't as flexible as sysctl knob. But, sysctl knob is = ABI >> >> too. >> >> >> >> > To ultimately mitigate the zone->lock contention issue, several sug= gestions >> >> > have been proposed. One approach involves dividing large zones into= multi >> >> > smaller zones, as suggested by Matthew[0], while another entails sp= litting >> >> > the zone->lock using a mechanism similar to memory arenas and shift= ing away >> >> > from relying solely on zone_id to identify the range of free lists a >> >> > particular page belongs to[1]. However, implementing these solution= s is >> >> > likely to necessitate a more extended development effort. >> >> >> >> Per my understanding, the change will hurt instead of improve zone->l= ock >> >> contention. Instead, it will reduce page allocation/freeing latency. >> > >> > I'm quite perplexed by your recent comment. You introduced a >> > configuration that has proven to be difficult to use, and you have >> > been resistant to suggestions for modifying it to a more user-friendly >> > and practical tuning approach. May I inquire about the rationale >> > behind introducing this configuration in the beginning? >> >> Sorry, I don't understand your words. Do you need me to explain what is >> "neutral"? > > No, thanks. > After consulting with ChatGPT, I received a clear and comprehensive > explanation of what "neutral" means, providing me with a better > understanding of the concept. > > So, can you explain why you introduced it as a config in the beginning ? I think that I have explained it in the commit log of commit 52166607ecc9 ("mm: restrict the pcp batch scale factor to avoid too long latency"). Which introduces the config. Sysctl knob is ABI, which needs to be maintained forever. Can you explain why you need it? Why cannot you use a fixed value after initial experiments. Best Regards, Huang, Ying