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 BF4F2C3DA49 for ; Thu, 18 Jul 2024 08:09:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 288A26B0082; Thu, 18 Jul 2024 04:09:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 238B76B0083; Thu, 18 Jul 2024 04:09:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1005F6B0085; Thu, 18 Jul 2024 04:09:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E25896B0082 for ; Thu, 18 Jul 2024 04:09:36 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D0720A1A44 for ; Thu, 18 Jul 2024 08:09:35 +0000 (UTC) X-FDA: 82352149110.22.DA9D7EF Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf02.hostedemail.com (Postfix) with ESMTP id B746880028 for ; Thu, 18 Jul 2024 08:09:32 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=TLjACtcf; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721290152; 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=tXMh51KVDkJmQr+NxLPzI9t9Kwi4FwG+tK/QlWBahKs=; b=fP1Ij3U/n6thr8ZNHLglAqM4L2rDsfBkuM2c9QjD2DnpMr6eeAinXAW7S+x3r7N6pWoHyd jWaV6XRp8r6nk4uxahqoqfUaK81xwKgqCuZqYdcqTZ+uYpTwx0Q5RhnXsxCz9HZb2kfQ28 4yMDpvcyYqhki3SeFAsvw8II644wfck= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=TLjACtcf; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721290152; a=rsa-sha256; cv=none; b=s9VE8gzBEbOoIM+RgA9yx2ubqLn980d/DWDPMEKHJqqGrU6XmMCFVVrq71w5rACVNBDJIi muvq0U5WJr6hEKJRt1R6UPfZErARDWR0aKMqbcNQczGaqRtUZegkuXsM79q1MdM4/orlCH 9Xpf2LCV2biYDQQ4CVBsIvO3eIBMdJY= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-52ea1a69624so38912e87.1 for ; Thu, 18 Jul 2024 01:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721290171; x=1721894971; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=tXMh51KVDkJmQr+NxLPzI9t9Kwi4FwG+tK/QlWBahKs=; b=TLjACtcfuc6z09DTuWMvb5aqoffAsZ8LMsqQrc/gUilY3Q04KluTlHp13bquyoEn4v a+nZAd85ZeXWkaxDzlTX7ZKlsmqZHF5VBqJht7fA4uVRnP/cBSfKyT+GJVKLW7ZwaxjP cInsqyepjYoufDA8Ch7LrP39CpxsEE6Yx9qWf7Zk2Mr43g6WgHfbT5FRIrWN505Fy+FJ KcwBpzgZRKGrbkZ6EEFWdZvmqPiRyfei+VA9s6PqxMvAw6dR5iVM/pm9VPewdX89je2V bRnXJ7ulXLLbPjsQtBSgtDvJMxrpyKGq0S5DPDVuIB5qF/Ce41QVKqyW9ntZEk2L7B0m GJhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721290171; x=1721894971; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tXMh51KVDkJmQr+NxLPzI9t9Kwi4FwG+tK/QlWBahKs=; b=e3fNqDwrUgmpLxCsGRDv33kfIXBlvyuGSB4yKywBeTBXPFVXdYKKpw/k6T9Ac0AxAT twxKaUdnajlkLd4SCaNzylImzMJDxKNt0kdDxjbWPzI9HRJz3CI+FSArZRHAeKw4Z2nK nrSAorHhYq5jDMb2lGMowxwNGPgECflzTPQR6uCcdHK+mPaY4diFcCiFx0sv3YEDHzA+ pNhlzRNhipJimpVinyyYXYFIGhCH0Gyc/0ufJWUa3MYrtjcXwQJqNc/ohUvRTVYG0Fk+ dLR9Cm8AXP9iNQchvQqRAJL2PVkLFWl+ujK7Rdcsv6Mk3keeinj1+BsktQmwETVlSrVK wr2w== X-Forwarded-Encrypted: i=1; AJvYcCUkbEnsNBEdO/9t/MVMEagdLNzEBDbueWyZgUrhdhaMZ6Cqf6ZMLUe5pAK9XLWrvku7IBH+N8MGbVKSWKfB5hmb0W4= X-Gm-Message-State: AOJu0Ywb5gg3E7wDgWVWXqecO4INOzQMfkxt7OqtQqqTHeaTrIb3v+5A CDdwWq2r6yysMXywGqlvbWds3mqC/kINhQdW/R4KC9P7vkqxtMDD08IbfjigD4o= X-Google-Smtp-Source: AGHT+IGegX6hhcdBy2hHYfDBsDRJkiHBdAAF1OXnxmmpbPiUGv7h+8z8jYIwpVOTdMuMRgTCMfHFxQ== X-Received: by 2002:a05:6512:3c93:b0:52e:7f6b:5786 with SMTP id 2adb3069b0e04-52ee543f25emr2769637e87.61.1721290170831; Thu, 18 Jul 2024 01:09:30 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a79bc7ff9fbsm531461866b.154.2024.07.18.01.09.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jul 2024 01:09:30 -0700 (PDT) Date: Thu, 18 Jul 2024 10:09:29 +0200 From: Michal Hocko To: Qu Wenruo Cc: "Vlastimil Babka (SUSE)" , Qu Wenruo , linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Cgroups , Matthew Wilcox Subject: Re: [PATCH 0/2] mm: skip memcg for certain address space Message-ID: References: <8faa191c-a216-4da0-a92c-2456521dcf08@kernel.org> <9c0d7ce7-b17d-4d41-b98a-c50fd0c2c562@gmx.com> <9572fc2b-12b0-41a3-82dc-bb273bfdd51d@kernel.org> <304fdaa9-81d8-40ae-adde-d1e91b47b4c0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <304fdaa9-81d8-40ae-adde-d1e91b47b4c0@suse.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B746880028 X-Stat-Signature: sokdr8qz44ros7xbft9cspx65orztwyq X-Rspam-User: X-HE-Tag: 1721290172-490639 X-HE-Meta: U2FsdGVkX1/6pbARma2Ped/Dnal0mh30rRudJg4gkW8LTY7QpywzMEpQ/nucje8/EUS15a+ijWn6Tyay22r9AaLRsR1vDNG+jjqqxER4lEGhI/4KS2Ch9LwioJl/J/W86BOVJEEk0HuiL97Ynwq2hVaKNeqXtwy/aA5IfEIPhLY4lSHLm20reDkuKzAmTIwsKJyR69lV+NWnMm9rSCGRJlRrgN5mP+gt2bC7tM4TshEfx+ugRZ8WlswdJTE/+8qrdbl6D4OeXbtk9wA/nX9KfFJxU/HNSW4Nig2txES7ZWS4vxKhxpCty/oPyukgr4D/QPO8C1AW6M2THd0MlD7/3fTbJC7WQJ4UWoCAcP7tLrPASeTHdmAkKm62Kt3Dfv9hTYPYnMlzNcl/sGB3+7fmcKmhDaYYx6F8CirBDsNWH0Kk5zP8JQTR/BTBdu1FiyPJPZYfqHskEkXrxVp3VnAmmta0jcFVORNsWy2OAP7O4W+L0hEXpGEgo7z2kXGkjDhUWzZpen6MLyMioPD/xBHDgIlDBZRWZaAT6DBm8OjBruWVgW13lDWjiEEmFco1lSTts2xYL8tz0ob4CM0S8xOOkVwtBfu0sGqAJiDVmGm4LN3e+yxma8v7kyKzr2xvcbYoiwUbsEKsKUaT2vW7LV3Kcu4MqDZZldLHMfX/7eCIK7iNrQBH9p79nM2kLYKNawP+uDTVZnPI6sEE+8UackT5X28lj/m6SE/xOXgFgLnBFMWzvaHo97Fpf/dFsYVsCK7HcgPBLTqSYME1h4Vn3AIJM8+Oe+T9R1pypOSovYfbFhPv/FkL2ZPeGsFf/RpdmxPCFudrFZ/HqZQOtb7icV2l7xD4EqcEa+ASOm3pJJaCWKXwc+AH8UicAhUSPSl4gT+XoRmvzgPfT8KWr1uXnneXd+8dmmAH4FVee5x/bW7a74Teoi7k8imMwiDrjGT51PQSebKCTpq/0eH4axRkmoA Be+9IeOS 3Ivoh0DQOk2Bb5jdNHe2rC23hR7LIP7w+wF9V9jn+N4RC42t+pBwFQunP8f3ydPTUXR9G4o6AP0xTrug8/JeVKm6HDBsQTweDccOzONOpY+UgZAVYzM1oiU5w71BnvTnMLFhKIfbCZVgBaacQFLYQvXcxPeJ67a4DI5G4lgrriW73O2soEV2Tby0Y052jbRmpOZjFm+BxbqMkA4Tc8nZ4UoUhgNr7KApLH2sq089BilVtvxO6u2VVfO3WRaV1ysGZSZ4b74UjDVauEVelep3Dmzhz286VuguKX0HGVq8E5D1/bacZ6HMQQ0k9zQ== 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 Thu 18-07-24 17:27:05, Qu Wenruo wrote: > > > 在 2024/7/18 16:55, Michal Hocko 写道: > > On Thu 18-07-24 09:17:42, Vlastimil Babka (SUSE) wrote: > > > On 7/18/24 12:38 AM, Qu Wenruo wrote: > > [...] > > > > Does the folio order has anything related to the problem or just a > > > > higher order makes it more possible? > > > > > > I didn't spot anything in the memcg charge path that would depend on the > > > order directly, hm. Also what kernel version was showing these soft lockups? > > > > Correct. Order just defines the number of charges to be reclaimed. > > Unlike the page allocator path we do not have any specific requirements > > on the memory to be released. > > So I guess the higher folio order just brings more pressure to trigger the > problem? It increases the reclaim target (in number of pages to reclaim). That might contribute but we are cond_resched-ing in shrink_node_memcgs and also down the path in shrink_lruvec etc. So higher target shouldn't cause soft lockups unless we have a bug there - e.g. not triggering any of those paths with empty LRUs and looping somewhere. Not sure about MGLRU state of things TBH. > > > > And finally, even without the hang problem, does it make any sense to > > > > skip all the possible memcg charge completely, either to reduce latency > > > > or just to reduce GFP_NOFAIL usage, for those user inaccessible inodes? > > > > Let me just add to the pile of questions. Who does own this memory? > > A special inode inside btrfs, we call it btree_inode, which is not > accessible out of the btrfs module, and its lifespan is the same as the > mounted btrfs filesystem. But the memory charge is attributed to the caller unless you tell otherwise. So if this is really an internal use and you use a shared infrastructure which expects the current task to be owner of the charged memory then you need to wrap the initialization into set_active_memcg scope. -- Michal Hocko SUSE Labs