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 755C5C30658 for ; Fri, 5 Jul 2024 13:09:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8E266B009E; Fri, 5 Jul 2024 09:09:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3F776B009F; Fri, 5 Jul 2024 09:09:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D064F6B00A0; Fri, 5 Jul 2024 09:09:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AA2746B009E for ; Fri, 5 Jul 2024 09:09:50 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1CC5B1C3234 for ; Fri, 5 Jul 2024 13:09:50 +0000 (UTC) X-FDA: 82305731340.02.71A66CB Received: from mail15.out.titan.email (mail15.out.titan.email [3.64.226.209]) by imf09.hostedemail.com (Postfix) with ESMTP id 34D4F140017 for ; Fri, 5 Jul 2024 13:09:46 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=techsingularity.net header.s=titan1 header.b=EG+gZOLv; dmarc=none; spf=pass (imf09.hostedemail.com: domain of mgorman@techsingularity.net designates 3.64.226.209 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720184966; a=rsa-sha256; cv=none; b=Lc+/EIlbgZy7/dVfxkvGlld+AxZ6ftz4IFX9k5e2DnWViVdoV+/wLOtd8vxd4rwjRbzLGy 5YwWv5e8KX7giVCyNut0wKSNFXQs2iFtzh92hpyxBEM1jZJZ8dNO12rEDjT6pRxltyierL ebseV5bSXv/kWQuB7K5YuNpq3w17C3g= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=techsingularity.net header.s=titan1 header.b=EG+gZOLv; dmarc=none; spf=pass (imf09.hostedemail.com: domain of mgorman@techsingularity.net designates 3.64.226.209 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720184966; 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=dAU+b2JYLCljJL9vPLgyxkSiqABvpWY31MM50nHOAA8=; b=GSchz8B2eLbV79lRzXoKsHFrsv7bhx+0Ru9d60n7mqiuePjV8nDFbG1IY526csSrtDKi+9 3cgEw1kF+nTOONggSm9uKsZGQCqp7fNHLTTu68MpzF+5QvB6ibO04iEiLvj9gKvF+siArC F7oYHrAY2r5OiUp8kt3eVTGscs4v/xE= Received: from smtp-out0101.titan.email (localhost [127.0.0.1]) by smtp-out0101.titan.email (Postfix) with ESMTP id 6AD1EA0052; Fri, 5 Jul 2024 13:09:45 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=dAU+b2JYLCljJL9vPLgyxkSiqABvpWY31MM50nHOAA8=; c=relaxed/relaxed; d=techsingularity.net; h=mime-version:date:cc:message-id:references:from:to:subject:in-reply-to:from:to:cc:subject:date:message-id:in-reply-to:references:reply-to; q=dns/txt; s=titan1; t=1720184985; v=1; b=EG+gZOLv/HKIOPx4pTVEcSsB8mcEgCv6oCNkNe2TaOoPbJ/bF0qbB9+ueHqV7ae8ksO6mUaT TJgUhapRgPoFiptQSyckEIbVLgPVNKI8lGhapbH/zlTZDGkSxc52g/L2pMZjnhajH914cOfVBtV V2NO1bs9GbnJ7kH9aPj4kNjI= Received: from mail.blacknight.com (ip-84-203-196-95.broadband.digiweb.ie [84.203.196.95]) by smtp-out0101.titan.email (Postfix) with ESMTPA id E5E72A0070; Fri, 5 Jul 2024 13:09:44 +0000 (UTC) Date: Fri, 5 Jul 2024 14:09:43 +0100 Feedback-ID: :mgorman@techsingularity.net:techsingularity.net:flockmailId From: Mel Gorman To: Andrew Morton Cc: Yafang Shao , linux-mm@kvack.org, Matthew Wilcox , David Rientjes , "Huang, Ying" Subject: Re: [PATCH] mm: Enable setting -1 for vm.percpu_pagelist_high_fraction to set the minimum pagelist Message-ID: <20240705130943.htsyhhhzbcptnkcu@techsingularity.net> References: <20240701142046.6050-1-laoar.shao@gmail.com> <20240701195143.7e8d597abc14b255f3bc4bcd@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20240701195143.7e8d597abc14b255f3bc4bcd@linux-foundation.org> X-F-Verdict: SPFVALID X-Titan-Src-Out: 1720184985303075993.8944.1984119938336885229@prod-euc1-smtp-out1002. X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 34D4F140017 X-Stat-Signature: a7wuzfcox64joj3jdaiu4cxzfczbspqd X-Rspam-User: X-CMAE-Score: 0 X-CMAE-Analysis: v=2.4 cv=C4+7yhP+ c=1 sm=1 tr=0 ts=6687f09c a=z8puceILRvkbfagoRYAjZg==:117 a=yLX2s/SMutoCvBNwHxSr4A==:17 a=Q9fys5e9bTEA:10 a=4kmOji7k6h8A:10 a=CEWIc4RMnpUA:10 a=pGLkceISAAAA:8 a=0VnFTwej4v2BQJf9vCcA:9 a=PUjeQqilurYA:10 X-HE-Tag: 1720184986-368911 X-HE-Meta: U2FsdGVkX18CvR732SvXRFGsoIqEb57F/L1nxSPEtUPR8yhyIlJeIkz23xSNxSxRCA3/WHKbGD87V9q8Ewq5pTzL/9Mkt3g4h7YpEY0Fy19qOJ53dqXhloA5yYtCpzoO3YWaCe4gPkzIJ1KkaMf3GEubelts5eM9iZEpYWLhbcL8Z1jptu/YqwkrUl3x16Vt3njXH1/HsF4b7kM2ArGh3/7dF1F5x8bFuMMxo0/efayOv/Zr+YpvlO6Aog0jbmdiErsEO2EZ1Vsm8YRfUg3TBmD8jL38SSsN0BfS2x3XRAT1aThi6bOa2U7HoHzoqT9ELIoZUIe987ONSLVJ3sm/XLX/bSpKs0SXvS0qioeYbx5iNhja9B79KeGE3qoh/A93zNNR4nf1jhyynWycYnSwC/40C48mNStdcVzRiy3ec3fcA1DwtG7/N6tAgS8oKg+Ydy6x9KoW024zSlKeIvbvqUjJyBpqNtG+TyiGEvq3WCxhqonlU5SBmr15t6dUMUR3CYsgOx+reNSkFXAkqIpkIcGEshOtFeHOCUSJX0jk3whEJLMPH4/oJ6iPEQ6RMsRam/bcTfP0utjHFYnQbM/ed3VrtStOUSohKNgTn4Ue7J5yZ2ku+UUAzhgVJgoeF3e+eyZ/szXBtTrYvhMb2d8J9GbjaFJhdiNzBcUYOjiV7SsUw2btQ7WsbO9b3xeLxWW1QbV6Hnp6XaeV/YKASQbVydGokTNA1C+R4lrkXwQ5bW5ekkF8mob3MXllbQsmA+xeEpQDU2UKEjTYiJPXhIiX7zrXwanyehZXzZILkEnhGTdIp7FWdu89AH/+Vxu1/7FNLshPXyI/1QAh2Tyc1y8sUlnALBz+XpqXRuXLCew4kd/MC2Qaz5hbcxOd8vl6ke60V0JMlpudeFW3VmJEZbUUOD3t3zSXLkOuGyWpIQgaUFaPHy+eTfP7wF6Tm1ZqGBj75Hb3/4IcPmT8Q9L3G3n RS5MlbXD 3O4ct1qCc5gN2Q+OQnrsb32TZWllCuJCHkZUOOa0O8l4AHm2UeB4YDuVmiV53kFe8PZgyfMrVqrPPHK3DaJsVrpRuXyTjPIzIpqZB62S7zAkb78mp6MPeqAUP0slsNREct3nyIjxCVTCBzzqEmDK25Kjz9Ra97hzL2qHPnEGoVslxLi5ENLGRjZzXyW4iCTi+Ed9oTbEGhBc+06Qpl1TcT+CW2yId9jW2/ec2gt1DPgnwxeprNbKD6AHcDadh9Aej2psSGEVttYWJANvD80rRBYPONu+TUr0/GD/wS5J8KUtGZNOD80fr2bCBVFF4XkaVM4DyXYVf4Q2InymtbRSH8Bfm/TSdujNdqgqP5/M6Wd/2/esjE8fcgflongfllW69h6qk9yF1SJviyNZCAf26jawdAh82d58Dv2idyEIB9F/SE1rGlt9ZfyrV5zrNGDbGN5+n3/YExBGYAXvr7Orx4yXoPCmPSha8VKJMgPhuODCSz50dRrvT2Ba/XCwKFwTNEZXhQj/uGMtcOvc6XgV61Ja5uTxJeDySP5w2D75F8y0EQzobY1Md6vnPOl5hPp+SoCQbZDKaVoNDrjK9NjM9AZ4JpvCmfPO1pAQ5vWn0eGH3Q5uHffWlhKBJvaqKEwUT1p3PcySLKwR0ouAgWE+TR6h+Nq0oAJ24KOI2MMkO4jbXoa8u0WZTP/pxA79zrc4Jf4GXayXQCROrIfauLqt36wuHzm8+5TTNVL5IX3XwrWmdJfhTaUK3W4jRdOrbvox1opGeO0B6rYCjVgrFTkqRy/1NJA== 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: On Mon, Jul 01, 2024 at 07:51:43PM -0700, Andrew Morton wrote: > On Mon, 1 Jul 2024 22:20:46 +0800 Yafang Shao wrote: > > > Currently, we're encountering latency spikes in our container environment > > when a specific container with multiple Python-based tasks exits. These > > tasks may hold the zone->lock for an extended period, significantly > > impacting latency for other containers attempting to allocate memory. > > Is this locking issue well understood? I cannot comment about others but I believe this problem to be well-understood. The zone->lock is an incredibly large lock at this point protecting an unbounded amount of data. As time goes by, it's just getting worse and it was terrible even a few years ago, let alone now. > Is anyone working on it? Not that I'm aware of but I've paid so little attention to linux-mm in the last few years, that's not saying much. The main problem is that it's hard to solve quickly as splitting that lock is possible, but not trivial. I am mildly concerned that more and more people are looking for ways of getting around zone->lock contention using the PCP allocator. I believe that to be a losing battle even though I added THP to the PCP caching myself. Now we have dynamic resizing which works ok but piling on top of it are file-backed THPs and THPs smaller than MAX_ORDER, folios in general etc. Dealing with that within PCP has limits and adding more sysctls to deal with corner cases is a band-aid that most users probably will miss. Working around all the zone->lock issues in PCP just delays the inevitable as PCP doesn't play well with overall availability (e.g. high order pages free but on a remote CPU), fragmentation control (frag fallback because desired page type are on a remote CPU) or scaling (because ultimately it can still contend on zone->lock). IIUC, pcp lists were originally about preserving cache hotness with zone->lock contention reduction as a bonus but now it's a band aid trying to deal with for zone->lock covering massive amounts of memory. Eventually the work will have to be put into splitting zone lock using something akin to memory arenas and moving away from zone_id to identify what range of free lists a particular page belongs to. -- Mel Gorman SUSE Labs