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 72DD2C47258 for ; Thu, 25 Jan 2024 16:36:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A70816B0095; Thu, 25 Jan 2024 11:36:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A16916B0098; Thu, 25 Jan 2024 11:36:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B7886B0099; Thu, 25 Jan 2024 11:36:48 -0500 (EST) 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 791566B0095 for ; Thu, 25 Jan 2024 11:36:48 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3A7E2A1C0C for ; Thu, 25 Jan 2024 16:36:48 +0000 (UTC) X-FDA: 81718387296.15.5AE7478 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf24.hostedemail.com (Postfix) with ESMTP id ECF5218000F for ; Thu, 25 Jan 2024 16:36:45 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ig63+Auj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706200606; 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=PzhKLh+3d9yOMQ6X8ivbWXymcJAfh+tVgCfjU+pI7Kk=; b=haNzLtMoIl50rKsFnCpfsejMRJcXsn/FY98195SzyrPJEdTX9iXrukdOgkaZ1VouB/DqIE S5jdwXOfDM3TmepD/0hJy5meuJKmBt3dHH4ejDQgPCclWvfovcTF3zGhCsUGQSFYOtbmub KGawv0andswsEewqee4AYu3jpFCRojs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ig63+Auj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706200606; a=rsa-sha256; cv=none; b=zvW5QKg5ksnXdylVD5odgIuIf23EP7FNerKNzOis1RLUNvNFCas5RatJS+P2InE+4DuMuw tzeNhRFTb5Iw6kqh3cI7Dv+7gHXDxgKvWwb9BBVEqqJks81AHvDBFJS4Is79tKJ4oE+Kgo wBoCsr32KGey9l2DBgpMbz0z0RsQuqw= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-55818b7053eso19165a12.0 for ; Thu, 25 Jan 2024 08:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706200604; x=1706805404; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PzhKLh+3d9yOMQ6X8ivbWXymcJAfh+tVgCfjU+pI7Kk=; b=ig63+AujalfjHmhpfyTSmkKUAO/SxRZ0qh3xzlvVl7I2iBD4yiY6AagHmA7sZ0bkHv uUserZofS8SKESo7+FbzFmkJCGyaKWMQ2bZbwxQ0hABhvACrA39gp2oa25F/n28GB5eO JENu2SHgB7C3jnzmdK7v895uQ1/G4cwaFZBrNHaJXpErU00yABRbB28czKieiymYMVoS 7OOoTZt1Fu9GO9KEpZB8n+2pQdIuy58VrSSfCMIvYQsh5gSxynDmuoC/PtphiOPLUUPc ujj/IsU2D9CakxfWiBhPbDPmvcAHnn722LaILrVO3/I5JfhGukeasproH66lvcTZc3xI DNMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706200604; x=1706805404; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PzhKLh+3d9yOMQ6X8ivbWXymcJAfh+tVgCfjU+pI7Kk=; b=Vc41Ew1KURG81OFOBIZ2qFCIgXPT04pH4ovyJDUTI74Mt+j+r54XbBaPf3ls28R41Q JV2MKHjNyVUzfWLwu8N/ddyQ8XvftHoW2BWXjVIwWtu58nSMOIPw6QFNeGpPYdMdSunT et0KdegmixXYm7EGj6OxQ3vjWQQnVj7oH7H+69eWoNZ6h42TG8ZWQtgSjm4+wccqSJi3 0jRlIj8mdKe8bxkb1u1TrRFtQFxekYfe3C0s9IrzGTG3+r4U2pXACSmoc/c6D2hCM8fk Hzaj8koIC5XY0xSyu2q3Q33EvLY5UM0trENcl47WI8haTt9j9E8yuEUaExA6l1LLc5rB 245Q== X-Gm-Message-State: AOJu0YzR87N29tugZF0wVouwxMJSPX0nqAjBFDJPQjVWN3JjMbe601Xy 3qEm8I7Udlbbe0i7jFcbp0sFOcFae4mEYBepdVkNhSjsilD6J6a/rK4mlsTrEo1VvKbYX47Li8j wTNTmWDjYAtL/ud53JYc4ptsUAmJpOZ9Qg7cU X-Google-Smtp-Source: AGHT+IE8Ob3eSw97oGgRaHA4aa3G3QI4B9MxmUAXtlZVNaBjYW+O7d1zFhaIc8srSbGwvw91lb7d+tmh6zH4S3XN0xo= X-Received: by 2002:a05:6402:1c92:b0:55c:eb69:979f with SMTP id cy18-20020a0564021c9200b0055ceb69979fmr185588edb.7.1706200604261; Thu, 25 Jan 2024 08:36:44 -0800 (PST) MIME-Version: 1.0 References: <5c7f25f9-f86b-8e15-8603-e212b9911cac@quicinc.com> <342a8854-eef5-f68a-15e5-275de70e3f01@quicinc.com> In-Reply-To: <342a8854-eef5-f68a-15e5-275de70e3f01@quicinc.com> From: "Zach O'Keefe" Date: Thu, 25 Jan 2024 08:36:06 -0800 Message-ID: Subject: Re: [PATCH V3 3/3] mm: page_alloc: drain pcp lists before oom kill To: Charan Teja Kalla Cc: Michal Hocko , akpm@linux-foundation.org, mgorman@techsingularity.net, david@redhat.com, vbabka@suse.cz, hannes@cmpxchg.org, quic_pkondeti@quicinc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Axel Rasmussen , Yosry Ahmed , David Rientjes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: ECF5218000F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: s19jspbm5k6ysy6ja7ir44sy331g4d48 X-HE-Tag: 1706200605-940766 X-HE-Meta: U2FsdGVkX1+CkIvN+Uoe2DCU250DE9zZmuxVCv9VEAeYb68/jm8zIZWlJ4rJH2xPBuMPPDbBSRcadzy8N0eyEbpeb2S7FGrDbm/FB2mf8F3NGyKFbCvtXwIE8RoT75PwS8jM4IvPLRCtpX0bxLEo09+1T6XZfAgYvho8tp6cL16Z8O7/64m6hgtf/PS1uvkA0TdDCjIKoFTXH8/sWyC58NYoxo5DFQ3TTg0I8FHLRaC/J7V+3qf3hT9Enb2LT+E3ix1j9M0AoYcWc+SXlRky6P1yfQ64oPiox87W7xgVOEttKQlblzrA0czR7pQpyFQ2uPpWp5diKQ4stPXZRf7A2DSvXDE3IE0dTKpoKposYGkj5TLVuYY0iip27vfKQppgRb/iQftSwV2F5GbfQSxlD9j+8S4qbPb21NCflurfnovbLX8LZtnaQwtDXp/PHaFLmXjWgswpPnKBA6jF1njn1RA3t9YX3wpZM2jrqlGy93+lip1EA3EqCL1O57cqf5JT27n9S+lZR6ZPOPHhU73mvVy3bbs2X+TxpxAxe/AtWmCtDlrgeA2mz8XjueRy269+8LjYxsHcOr+O0zSVlLKVejUaHTmw4JaF60bbwn12Gq6KYmYMarajzl92C/BB7QQ7tb/D6ozY6zmFPI0kGFlww4YIuG1Lqb/PdCQvKkmO9YiGZAxvzMDyjWlX93MVtnQc9KT2R78SRNVnAu73flTaq9FCGSxqa82wi7ozu0FYpZXlqs41NLxl50PaLwKzhy42e1jG4/q/YAV+Z469AxKmAfy7RV/yhjDbOLAe6DJ7cueZEVTi1vOYEs4M9NqOmWsRm1IktP/l7TCWKpWcIQMbqd/GKQtTZqm9+yPzBWwqVsnAWKbsLITE5aH+xZAq69p78YYPEflNA1hc8ULKyNJL1nt82htEAgqXA10kdZqs4c1SDnm1WiUJRjOMdQ7r4XA3qYY4pmZyMVaexGgYMw/ yVhNEqfd MJ+uKd6V7zoIlxLLh8cQMdDZRzCx+efUjMIj7amJ/eC6XjgcpjElixRo8Xi4OX97OXUT+GBwACuYHrVWg3xJcZCI2fuImltlc5gMUyqjINtTQ3LsESD015wwUgcPggQKe+T6HSLl/w7W9gncoIVTYk8SsoXDTraPSJw5yikui+e3IBS3RzXimz1yCmiEpF6KU1ZX/FnweadAH3ACl0gIQwCTuEQK/gguDj0BXaFtQJDWvi7lBztNXyF6TKx3qrC0Grh6fzxyMIVV+T6wTmT4bbnKagppuzHrDKiVjhngq9E7s0VbsdUFqkae42ut56A8BsnG5j7PxEwLWcRLvvj+Es/trOA== 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: Thanks for the patch, Charan, and thanks to Yosry for pointing me towards i= t. I took a look at data from our fleet, and there are many cases on high-cpu-count machines where we find multi-GiB worth of data sitting on pcpu free lists at the time of system oom-kill, when free memory for the relevant zones are below min watermarks. I.e. clear cases where this patch could have prevented OOM. This kind of issue scales with the number of cpus, so presumably this patch will only become increasingly valuable to both datacenters and desktops alike going forward. Can we revamp it as a standalone patch? Thanks, Zach On Tue, Nov 14, 2023 at 8:37=E2=80=AFAM Charan Teja Kalla wrote: > > Thanks Michal!! > > On 11/14/2023 4:18 PM, Michal Hocko wrote: > >> At least in my particular stress test case it just delayed the OOM as = i > >> can see that at the time of OOM kill, there are no free pcp pages. My > >> understanding of the OOM is that it should be the last resort and only > >> after doing the enough reclaim retries. CMIW here. > > Yes it is a last resort but it is a heuristic as well. So the real > > questoin is whether this makes any practical difference outside of > > artificial workloads. I do not see anything particularly worrying to > > drain the pcp cache but it should be noted that this won't be 100% > > either as racing freeing of memory will end up on pcp lists first. > > Okay, I don't have any practical scenario where this helped me in > avoiding the OOM. Will comeback If I ever encounter this issue in > practical scenario. > > Also If you have any comments on [PATCH V2 2/3] mm: page_alloc: correct > high atomic reserve calculations will help me. > > Thanks. >