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 61195C4828D for ; Tue, 6 Feb 2024 23:16:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7E886B0074; Tue, 6 Feb 2024 18:16:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C2D456B0075; Tue, 6 Feb 2024 18:16:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF4726B007D; Tue, 6 Feb 2024 18:16:52 -0500 (EST) 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 9F95B6B0074 for ; Tue, 6 Feb 2024 18:16:52 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 49BCA1603B3 for ; Tue, 6 Feb 2024 23:16:52 +0000 (UTC) X-FDA: 81762941064.22.7F6545B Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf02.hostedemail.com (Postfix) with ESMTP id 7F29280023 for ; Tue, 6 Feb 2024 23:16:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GhnhV2L5; spf=pass (imf02.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707261410; 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=hjuXYFp0BpgB4Emdhlo042pzBYM3c/njLOXBtfjA7Dc=; b=YhCgxBlT/IurCdgE7hsN0/SZJuZTLTTZYpbHIvk1X2+lO6BB8hWEp5d1t46uVHU/U5AwzW dKLz1DIlNnMxdntXL6iLp5Gy+UMhxkXj4jVbu61Kh695TLNKn5TeYCKNbtghOrcsYjZXfh vSATTkjzUZgEjAP4qArszl89RpC4Oxc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GhnhV2L5; spf=pass (imf02.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707261410; a=rsa-sha256; cv=none; b=2Hdr4TNQcQg9ZfJLjeI9mpBc/Osfd505OQ7GQxtqUGjqwGfCyXm3TTvSFMwlXyDnmoXbqs tKcJVESZ+NL0GHc9ySxnBOf0/UpC0j7CytrddJ2G23nRMv2OnNyURXGn4lvSG9Xux6kp/K sYJ1Pj7/eLGso7qGDKiar8elpPohN24= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-56037115bb8so5241a12.0 for ; Tue, 06 Feb 2024 15:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707261409; x=1707866209; 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=hjuXYFp0BpgB4Emdhlo042pzBYM3c/njLOXBtfjA7Dc=; b=GhnhV2L53Fsu6GM+fWls1OZ0nTlcpjdnGLcfrz8MEgkDMfp1EEZt1PQC+NQEHyFcOZ h0sFifyno8c89YOPfqznuN0lgfair0GfiRkd0qEHdqpEv6IWmAPcXBaAa4wEI2f7DsxU hWTqmS1eY0coFD5z7RF0Z2BpLiMEcplz4COWP48O43ZtqGpzmZIMSFumZN9DmTQgSlnk +tVNFF96Dvl5tcV/DssnKKO68Vp1bqr0v73f1Xw9XlgB4OEQURxBeTChCuMem9q8p19a QhOWrztVg48G+WSw2sP3jXGTzWdO/rBeh62zX9rG7oxXO781Ki3IXREgM0mqUzgyMhE9 JkXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707261409; x=1707866209; 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=hjuXYFp0BpgB4Emdhlo042pzBYM3c/njLOXBtfjA7Dc=; b=VSpebhbTXNZVZlHUhvsUm2+n/MMHLLktzzh6QkEax2yWdibkQEN9uU6W3o0ykc/Ghk YC4nhzUumAjmPWLQCLfK/uch4s+aPeeKTcrFLeV3u7Yr5qrUBcJKZqxWaf8ntg6pB6Wv PKJVBBo0LBzlk2HEnQqGWYWjHxooy3wYCR1ctwLzvxlZbGFupK0mzFicWuJ+lxlkutgn 8CE0U+tfWiTDk88M+1hBLb+vtE4jw3ZKwQxD4rqLN5QZxwBrrN2GzabHh2PMYjlTsjpO sVTysNMGHRlNGmHfOfGkwEg5zd6TgsxAc8akm55wFWefxm/7zKOFYX2LhTKNb77u9mBd 4xmQ== X-Gm-Message-State: AOJu0YxmBo/doHK7tLqJzyxwpacrcqb1anm2Yokyv8eye7Ltu/ROm/yM dq7RXeJSo2sac4SDmz1h+GTa87meb/v3zkBQRPmm0si46yNXA4QT+eSLesc/MRh8woUyiFY3EBg gKc+sBWZAhQiScT6qbi1tjCybL+5TosdMK7qS X-Google-Smtp-Source: AGHT+IFVLHOeVS3oFWFpqfR2BnXJ2QDNRGI0rWqOwWejn1ZrttMuYSvIlJQWucqQHUWngwl2NRRgXBVL/bLssOk8rXY= X-Received: by 2002:a50:9f08:0:b0:55f:a1af:bade with SMTP id b8-20020a509f08000000b0055fa1afbademr74668edf.4.1707261408799; Tue, 06 Feb 2024 15:16:48 -0800 (PST) MIME-Version: 1.0 References: <5c7f25f9-f86b-8e15-8603-e212b9911cac@quicinc.com> <342a8854-eef5-f68a-15e5-275de70e3f01@quicinc.com> <5adb12eb-8403-5860-28eb-5f6ab12f3c04@quicinc.com> In-Reply-To: From: "Zach O'Keefe" Date: Tue, 6 Feb 2024 15:15:38 -0800 Message-ID: Subject: Re: [PATCH V3 3/3] mm: page_alloc: drain pcp lists before oom kill To: Michal Hocko Cc: Charan Teja Kalla , 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: 7F29280023 X-Rspam-User: X-Stat-Signature: 8ooisc9urseagyg7ewrrxdcmk56ayaeu X-Rspamd-Server: rspam01 X-HE-Tag: 1707261410-267850 X-HE-Meta: U2FsdGVkX18hgNLz9uR6iPHreCA+pz7u/fKG8FjI3tY1OtkYpgxc7qtZ21kwmgYquO8DxteIEp/wpKZNNlhPWutZyYl2dVuixbnowCRpnJGdtCLYEOuSMNh0mxwAbIojBSPueE6rl4GvhQIAheRwLNINGvgthRvl2BqNEz9vbWxyGKvqr7ynTam3i7nVywMdARyLXEv0SEBKT6A9WY6Z7PXSwB9mlLkMceiRPx3i1Wqs49gnMR1eItVrGyUOo90/u6zuM1uFP8On9vDmQGJxr+HFOUqrsdqHEFa5o7RpWxURDcfPkRkaHE2IfUEqUz06Wd4WQt+l3HIL5mz3N3LmWLx6+GVKPKoTi4oZ4jTp9ndbcyfwpNvO16Aa7D1IqyR/uofCBPKVDYWknO4pVcoMJlnGjDlV0w83pWoCkta4xgZ4e1c6lfzoeMn0iwPFhMgx8jKZsh2Ici7EQXATE4kawdSfgnJYjGgG9fnXOFWn9SLgS16tcyDamYjH2j7Ta1KxYWPCKF2JJ06C3ms3YTTZE9/+/jDFwTGCtttdw4DGb5a7S6xRsKWJ6ceKcLOu3bZI8YIjLYsXWuN2p+eBvyVYkEmBqpgLgy/2zH7koHWlabhfiMxWGozRmWpkLE2pTJqZ48VUCqnbI+mggfhlRjr2HUcQvJLxfT1GYxSis+aHj/rxabgA6I+Mv0Pa7it0/eFTCvxvyYA+gvOMY6eZZA6ShC6HEnD3Avvt5qA+qig1+D9ez2J05C0dEceVHf0XowMuO1uW3MwXGNyMy7ZiCljBZCTK9hpCNDn1heuezwxj5GEKjqYf6UJhxM4xoEKGku1899GJSs77LgtRKVAxFPq52/2c5lOstI5njqq4oC2U4JIAbs0zhOxGZAa+uXSIgBJw8rm9cKYb71b6uDpur1eDYY3C60k7ADWrD4+FgiZTUJ/Bsm7eyTJRvk0Nl1lg3pJGxl42rAgHR1sUjU5VcPD qdTR72u5 p5I6kUNN60nhGQuPD84UX1KiRkifO7uDU9l3Yh7IgOtqG5jZSSgVDJX5ntyFMJfG7UKcQbUpOkD+YCKWEJvHyX45ipqZHeADjxqmjeKdXuwlP/9yLOUGbS2wyOwiT21hMkwC9V8JY7F7uq6eHw1mLYoaI9/+/RhjAsxPLSj1aruwDDdIuzrrgwRT3cUEEWVee6EzWBuQYFj8CQD18voxlT2PKcTkZ3x+/p5/GMkN45qUdg2r8emI9HntVSjj9H/AqD9YsYqVuh9I/f1fIzCEUPpgUrvCup+pnXO+kc5N/B5hEdmojuZYwq16V59mB60IWywzi61XDtqc2jnWvRAY4NEqknRvS93qKYqbKN/OAIeWT5QW+6At4HojlpuKcV3XQ2rtPJBV0LuQ5OJHndypZdZWbHyktndSWB62L X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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, Jan 29, 2024 at 7:04=E2=80=AFAM Michal Hocko wrot= e: > > On Fri 26-01-24 14:51:26, Zach O'Keefe wrote: > [...] > > Node 0 DMA32 free:66592kB min:2580kB low:5220kB high:7860kB > [...] > > free_pcp:8040kB local_pcp:244kB free_cma:0kB > > lowmem_reserve[]: 0 0 16029 16029 > > Node 0 Normal free:513048kB min:513192kB low:1038700kB high:1564208kB > [...] > > mlocked:12344kB bounce:0kB free_pcp:790040kB local_pcp:7060kB > [...] > > mlocked:1588kB bounce:0kB free_pcp:253500kB local_pcp:12kB > [...] > > I'm not familiar with these changes, but a quick check of recent > > activity points to v6.7 commit fa8c4f9a665b ("mm: fix draining remote > > pageset") ; is this what you are referring to? > > No, but looking at above discrepancy between free_pcp and local_pcp > would point that direction for sure. So this is worth checking. > vmstat is a periodic activity and it cannot really deal with bursts > of memory allocations but it is quite possible that the patch above > will prevent the build up before it grows that large. > > I originally referred to different work though https://lore.kernel.org/al= l/20231016053002.756205-10-ying.huang@intel.com/T/#m9fdfabaee37db1320bbc678= a69d1cdd8391640e0 > merged as ca71fe1ad922 ("mm, pcp: avoid to drain PCP when process exit") > and the associated patches. Thanks for the response, Michal, and also thank you for the reference here. It'll take me a bit to evaluate how these patches might have helped, and if draining pcpu would have added anything on top. At present, that might take me a bit to get to, but I just wanted to thank you for your response, and to leave this discussion, for the moment, with the ball in my court to return w/ findings. Thanks, Zach > -- > Michal Hocko > SUSE Labs