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 193A8C2BD09 for ; Tue, 2 Jul 2024 02:51:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19A646B0095; Mon, 1 Jul 2024 22:51:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 123D06B0096; Mon, 1 Jul 2024 22:51:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDED06B0098; Mon, 1 Jul 2024 22:51:47 -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 CC1E66B0095 for ; Mon, 1 Jul 2024 22:51:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 71A4041961 for ; Tue, 2 Jul 2024 02:51:47 +0000 (UTC) X-FDA: 82293287454.05.8366AA3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 6C75F2000E for ; Tue, 2 Jul 2024 02:51:45 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=I70yo48i; dmarc=none; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719888689; a=rsa-sha256; cv=none; b=A1mJHxNiVe6fLFpSgopDTEfoIwA+XiJf9h9GBp6uyVycwDHJX2n1gBdrhsGuyxBI8tif7t J+e/mUDnljp7eAfOYZ/XBM5CTkXeFtU+uOOXeUZ/dC/LpR2onMMKzQhlsSrMxswNcnUHGT P+c6JbXD6VuYah2sWjLoLZNe5eaLvuk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=I70yo48i; dmarc=none; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719888689; 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=6qlc2paZkse/JKGzX7EG7MYfUjD65TfhN8vSUnfECrg=; b=1x3tWy+8JwQOsfhTuolJ+faTdHQqj9HGEshnmEXHyu0m1dI0d2CAhyuZQw97tTaS6BEFc/ P2aKmtrc+Ed0zx63OAIPl75nmxI0TAW+T/XO0SlMJWiA+HFHlEFiqTZrWY7TqXuWz9OQgw Ld7bZT9SkmrgmcUPBjubJFL/bKSp54Q= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4C70361783; Tue, 2 Jul 2024 02:51:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C72FCC116B1; Tue, 2 Jul 2024 02:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1719888704; bh=EoUGh1ZFvuBVj8vypBMEooydAiMglq5iT6CAovpP9p4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I70yo48iusEecGypPLarHv9Vx6X5X14JGCMmD38TB702xsFlyHwbGkARN+NM6drvx WGm7ypDcpU8KA/u6j2kfGvWGRuI5PZF1o5f6ny6D+u8TuU9h17SJq7fbm4B6Qu7Q3K oddmTXH6u7zvjeQckTb5lFhhH/KTOwfwkxlXLzm0= Date: Mon, 1 Jul 2024 19:51:43 -0700 From: Andrew Morton To: Yafang Shao Cc: linux-mm@kvack.org, Matthew Wilcox , David Rientjes , "Huang, Ying" , Mel Gorman Subject: Re: [PATCH] mm: Enable setting -1 for vm.percpu_pagelist_high_fraction to set the minimum pagelist Message-Id: <20240701195143.7e8d597abc14b255f3bc4bcd@linux-foundation.org> In-Reply-To: <20240701142046.6050-1-laoar.shao@gmail.com> References: <20240701142046.6050-1-laoar.shao@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6C75F2000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 14e69j1h59537xpicjitqtt9uge7xsqa X-HE-Tag: 1719888705-159363 X-HE-Meta: U2FsdGVkX180NUEf+aZ9P0B7EYVpHC7AZHLb3x0tuFYyONBpWH+18CPRI5OwJ8HCGSCBvsgCxpI11Owl82EoaTz/OnwKiP0x9csVokNg+7I8howsdrskG0O1jkiMSFbJRBRK81fTre0piKWtPucX8SEfX773mb95ShZa/tTQNKR9pkcFZX7vbiAdtwU/6DUepudOEu/4NVHm5BxN89sP22yc9nAm27nyZ90plTSXlL5Ly9nLfHVJir6sAwOdjq7ATe27f7XkB7fLcY8w3MMKFR/NvXlHAj25eNmmwVGMb5nCPYaOadP1aJi+Ffn/2Zferpre2QHcigMrQqOltyZcbhCVDlPJvPC96v1h/fgFHROhZ0xyuXdWfk/q0zvmB8y591t07rrBAftPn6GKIjAuMdX1kpy4DDm2BrHZ2QmgUkiHGLl+RzCtIxYliGF0hwOnL2RtQTh7Y12LY6vjDHgcpvPHe2DItPgl7x60GIapv7GnvkDUFc7dxrFHqbE9g1sgNzF7fn1Sath3n+hxFOzpT2TrWwrvmNng4JZMM84g5doXEeNQ5OpiVkyrwtA7uxHraUvJHTMOk8MU1Q43aT57toGyKSqJHOo2unn3i7W+4oATGBeamuFHzM6WVChrDAAvRn/UNUKfFAac8Axa06xKFlWZrr2bgiCjg7hDgE/oJzi+MPhrbKxBvgzD4ehtiBr23lL520hNaWM4I4ABE9H9b++D+zNi6w9uY2s2FOVYCvYzcgdPadsdq5bO7vWLiF1zc1jqYZB+JX0YsL/kjX2Oi0jorlKIxlMoZEqlgBFWh+CW++Z2mRxW0sy0FB7sM+iKgipJjJXfFjIxb6Kw9+C1WvAt0Nh8po3P39alquRCV66gktr/LwH7veT463PbczUjy1AWt9oC5GD9HfUD0jGI1VgXN3CvIvZnnE7mYw1Ky0XrTh+yt84rKfA76ygcbnMrKHBVvE9FEUVeRSyTZRs IvF0Cc38 E/tHFJF17wgJhpZdLmZOLq8BMVttrJpuG5183fL9M/1FKCS3oBr7eDiutuuHfJEXTPa6n05Qa0hql3/B7lSkU0TWJqBrMyBdWW3a811paw+utjqsbH6QMHQLZgnF0ZIkBlNGuptaXgKliij4ZoS5fnOL8kn3Fh+9/L3c9I4rBiJN/BcTqQE+dpIP+tR+pBQ4aQHGfxoAPRZW4fj0Z+5AdBY+iCsypBWl7hgjq7wg0eKWGNdL4k7KWWRBni/rdAyKV4r3YUENr7f1CBcegw4DVR2UuIIJLL9pMfiePal9Lgd1TaoieTmKwwlUoW5Rz7wYC1ea9ilb9YYSikgvFQ33Ppg+LFy0mjAnW0jdlRP5qWQiMgWutmr+2vykd4Q== 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, 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? Is anyone working on it? A reasonably detailed description of the issue and a description of any ongoing work would be helpful here. > --- a/Documentation/admin-guide/sysctl/vm.rst > +++ b/Documentation/admin-guide/sysctl/vm.rst > @@ -856,6 +856,10 @@ on per-cpu page lists. This entry only changes the value of hot per-cpu > page lists. A user can specify a number like 100 to allocate 1/100th of > each zone between per-cpu lists. > > +The minimum number of pages that can be stored in per-CPU page lists is > +four times the batch value. By writing '-1' to this sysctl, you can set > +this minimum value. I suggest we also describe why an operator would want to set this, and the expected effects of that action. > The batch value of each per-cpu page list remains the same regardless of > the value of the high fraction so allocation latencies are unaffected. > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 2e22ce5675ca..e7313f9d704b 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5486,6 +5486,10 @@ static int zone_highsize(struct zone *zone, int batch, int cpu_online, > int nr_split_cpus; > unsigned long total_pages; > > + /* Setting -1 to set the minimum pagelist size, four times the batch size */ Some old-timers still use 80-column xterms ;) > + if (high_fraction == -1) > + return batch << 2; > + > if (!high_fraction) { > /* > * By default, the high value of the pcp is based on the zone