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 EBDF7C28B2E for ; Mon, 10 Mar 2025 10:56:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ADB66280002; Mon, 10 Mar 2025 06:56:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8A4C280001; Mon, 10 Mar 2025 06:56:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92BEB280002; Mon, 10 Mar 2025 06:56:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7404E280001 for ; Mon, 10 Mar 2025 06:56:31 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8F71A160D57 for ; Mon, 10 Mar 2025 10:56:31 +0000 (UTC) X-FDA: 83205337782.05.1A08F73 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf16.hostedemail.com (Postfix) with ESMTP id A03C8180011 for ; Mon, 10 Mar 2025 10:56:29 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nSqZGBP+; spf=pass (imf16.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741604189; 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=wGRxKiBJ9FQQRTK6oDzeSg0q1uR8lmPV8PHL2NFq+zA=; b=6y8fg6f1JUeJiAp/g57yeu1/lMm7HNsELTA8YXk89ncGDg+RVolHkgIwYHyt8QDJqhiDpG z0vDUl221IaF+8Z37GrvLLUrBxBA5aiqJNfVcfM1w4yCNZu1GwARMMxuQbzrvkM62rSD/x 7c6WMO39C4yIr6kXk+of7HgQkPXYKOA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741604189; a=rsa-sha256; cv=none; b=J78+C68PNHT1ZTX+106NVtXiwjYCxfQQFuNHEXT58qyghinjUS7q7yqVlM1JoqY3SXtyDr 9oqIsSqrYtHLt5R8My+2sx4dkyh1f7fb4QItdvRgo6CgQQGuPb6Ct5OLjL6Oo1T9kIIR7E TonRcJ4GPtDmyS779/pVkkXjasck1t4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nSqZGBP+; spf=pass (imf16.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-390effd3e85so3565450f8f.0 for ; Mon, 10 Mar 2025 03:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741604188; x=1742208988; 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=wGRxKiBJ9FQQRTK6oDzeSg0q1uR8lmPV8PHL2NFq+zA=; b=nSqZGBP+jBcoHQQ67Ce7iWMLYH/rCi4RFIAJ18zTntUj5Vk6ASnZzbyOr+n7TznxjA PQz3ITWvFgboiuza6pg8fkrunNdQh4vANStqDzubmBUGJbmxt7sg0Owh34r+aSUSbC5s /0FIT+46867QimvFRb4wrJzn8ARO/axYSnsS8XP9zubjsvl+rTWJ74TdSL1Os/uBSBb3 soWfXSBNWUCUanyJZ0OK26/PPYfrWntW1uoz8jp4T91a2TFtA6u4DKcNYRawyboAUJy7 maOXzS7hFF/yA4MmozhQoCHeEpUCqnWiZbol5miisYfjPp6rEu54p9+oYWbnZEqmWopq imTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741604188; x=1742208988; 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=wGRxKiBJ9FQQRTK6oDzeSg0q1uR8lmPV8PHL2NFq+zA=; b=pWOPzTEgE4cxSNQfcb2T5jmMujgr9M8OViuvFieOP3sJVk4DiipZeMbHPL3jaA3t7+ HUUSgcS0WabM17H2TgA8AXxQeuGady+MPPf+NyYrXQi2OCSKdeRzUAIjCSUwfCCmOvg3 rAGC5jVjw/MKswbirkA6/lxrOSdj3fXwCZWJ2Z14ml2OjFkZBAaVEHRNNM4cxOjG0uZI inKLGr1AzowXDGWbSxjZWUVZw42J7bT8H9aAIwZGyqZ4vmEVxHYZtJOmbaF5Rz6rSwu4 xFKZUjXK//h3p2m7wDwfI5D8H9ywbbshe4dO41aWTZofmzGc29VSEGWtwG7zt3wRiWeC lNjw== X-Forwarded-Encrypted: i=1; AJvYcCXlNygYmXuRwDIANaDidzoaAghOBHTlXfNmXOG2vUZ4nrcYdS45gzH72H/c5LirondG/prcGuGFbQ==@kvack.org X-Gm-Message-State: AOJu0YzQNB1dOaPq6MZo5gb9y0JhJ7ExJdOs9Y5I/NBOkCUXGJTQS47k LVy6NYUcIH6S8oIGEhAtGlPD1YDx4k/YYfx8Dj8bOJip9SwPnNwfXyWf5T+tjlmswgZDEG7pg7+ pbRyVOnylPtYa0pjaxyZypnuBHBg= X-Gm-Gg: ASbGncsR/GoTYZyTqzRDeOZ0526pCjhGIPYqJVqH0F7Mz/wi6BiM9P6iv0pquHEHthE Vce7D0yrfDlCNF26HB7sjROUU484yuTUgnRTP6ggtwWW8W+CCasSPhe+mVvOsjXlXl/JQrdobsx WaDV9eyTfcfYSpKxcYLzKF10+K5w== X-Google-Smtp-Source: AGHT+IGYDB/hh4zokMCikpkMPS3SEWZMqEvFe2ojibH66A319Zc73ywxFVPR2jPBB0VrzoRht/KJKUB7T8KTdt9OssE= X-Received: by 2002:a05:6000:4013:b0:391:3f94:dc9e with SMTP id ffacd0b85a97d-3913f94dde0mr5331464f8f.16.1741604187611; Mon, 10 Mar 2025 03:56:27 -0700 (PDT) MIME-Version: 1.0 References: <202503101254.cfd454df-lkp@intel.com> <7c41d8d7-7d5a-4c3d-97b3-23642e376ff9@suse.cz> In-Reply-To: From: Alexei Starovoitov Date: Mon, 10 Mar 2025 11:56:16 +0100 X-Gm-Features: AQ5f1JoUrD98AB14rnB1IKdkRt4DsRzn0OxlMkGJPDtUGy7hI_dYyPsJBkJXofA Message-ID: Subject: Re: [linux-next:master] [memcg] 01d37228d3: netperf.Throughput_Mbps 37.9% regression To: Vlastimil Babka Cc: kernel test robot , Alexei Starovoitov , oe-lkp@lists.linux.dev, kbuild test robot , Michal Hocko , Shakeel Butt , "open list:CONTROL GROUP (CGROUP)" , linux-mm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspam-User: X-Rspamd-Queue-Id: A03C8180011 X-Stat-Signature: bedngiowtig7w6bfn5om3sb9agf33wp7 X-HE-Tag: 1741604189-165146 X-HE-Meta: U2FsdGVkX1+WUkXlrNijZYAIwWaxEzXHOd75kjKsAn68n3IdfW2CZJfT6A4wHiGoZazzwVrvnlGW5ZA2XnkPZSwDgeiRSfAiB1dfkqDvGkynpk6/6PShhYhIxhZQWn7C6w4Dz6Di+weizmgTh/ue+PaDQ5Kzt/+OzELdMv/xnA4IZdlLEHK3LyIxXkJp2Epfiyv83fDfJ0YvxMUesoIYVGnckz1rUcbLiqYL8axI5p0VmShY1ZNwRkmwrY9NCmogeUlV46bM7WBczOLascNrl3CTXGngyOwfVsBVzMnMewb+q/0muOqSkR7bcXlOJqXLE0p4tGNIh/liPbWEL+c5cfPG/D+5fEawxWJ/oy9fpXrKJjlb5jmpm7KzwxrgmdESMksC63BTQ+jwJTdWkdrGGCpHFuuHK8XRzQv2YfBRgE3e4z8CzEMaI+gUp5cHALGEAjWl7CKfqJ1Gxz4bOESFnHkWePUhqV4KGyfo21GWMpTBfDXpd4VuxlGHAJLLnpa5KG5lPOzDaP/hZLIQolxHNYPkQvOssz8rdKMieDGzGKdr/Mdm+KmQKqTvFWa/bmFtwj4SzyQ2a/W114sopYejfBECgJu6P0YZztC0KvpmOxcRRqhkNTBUrFzFYAGCnmMjWaic6htQHcAQfvb07MKOJ6L0J4h5sSieo3ociaJ6VP3HXiDqoYcAyCczzWNbVBOMbC1bFrdZYs8zCrIxc4vawzqb1LVDdgrfDhK/Om+wJLZoEMsT4qkZMzTmqzbLq9uvGNwNgnU+LXd5SXr0HJ6LxPU9aBaPAvmlMVcjTUy1qTspZY9vDyL+sPsuIg3/mc0zkHmLB0hPnSLLGsk5Y0X3WPjjeN9i6pTGbcxtFa8ZMtKBULU6+f6I6SPhX8diRaDUH/ug9/+Ig6VO3wfDO148AiXCyj7NIhzInPvL5kKcxZUmL1/sA1Xnoy3dH/9r/+k3TQhghni7lDvXkOBwCBT JEzox2Ng CGl/T8yLjwo/qxzUZydi60ysJpbeaf26jL7U9mphbKRx6wI62BR2VKCpwSWtfehZ+PnowfpaFHfL3MC5s53aYYDfGrEHLQSVQtltoqcNgj/WMD106sWneEymmAgjFnWucx8YGEiZ4VuftyUTD7TzpHzttw+Q3fXCgoONwDh648KBZvZpAhzB91bojLRQzDbUFZiqWuHLeDKLUjaX4epvRktU/dymsvcW2+nIRGygDEp40OfCAv4iFZxNKNnrTu4EA0m+UxNw6Yi1dtDspLwqu3uxnMWIpJzVWr+fkPMlWblO3498b/Wq1APEMgoKjkygfDp3U+1Z2sLGRrL3RJ4E0Z0zgpn1RAP/iO0tLx/FtO7sJU9Qm1nF/6INUsomdtiMa9Yc5IOSktYZgW/c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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, Mar 10, 2025 at 11:34=E2=80=AFAM Vlastimil Babka w= rote: > > On 3/10/25 11:18, Alexei Starovoitov wrote: > >> because this will affect the refill even if consume_stock() fails not = due to > >> a trylock failure (which should not be happening), but also just becau= se the > >> stock was of a wrong memcg or depleted. So in the nowait context we de= ny the > >> refill even if we have the memory. Attached patch could be used to see= if it > >> if fixes things. I'm not sure about the testcases where it doesn't loo= k like > >> nowait context would be used though, let's see. > > > > Not quite. > > GFP_NOWAIT includes __GFP_KSWAPD_RECLAIM, > > so gfpflags_allow_spinning() will return true. > > Uh right, it's the new gfpflags_allow_spinning(), not the > gfpflags_allow_blocking() I'm used to and implicitly assumed, sorry. > > But then it's very simple because it has a bug: > gfpflags_allow_spinning() does > > return !(gfp_flags & __GFP_RECLAIM); > > should be !! Ouch. So I accidentally exposed the whole linux-next to this stress testing of new trylock facilities :( But the silver lining is that this is the only thing that blew up :) Could you send a patch or I will do it later today.