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 0DB5FC3DA60 for ; Thu, 18 Jul 2024 08:52:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E01D6B0096; Thu, 18 Jul 2024 04:52:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9687E6B0099; Thu, 18 Jul 2024 04:52:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E1D56B009A; Thu, 18 Jul 2024 04:52:22 -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 5990C6B0096 for ; Thu, 18 Jul 2024 04:52:22 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0939480DE9 for ; Thu, 18 Jul 2024 08:52:22 +0000 (UTC) X-FDA: 82352256924.15.5306341 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf02.hostedemail.com (Postfix) with ESMTP id EE91380012 for ; Thu, 18 Jul 2024 08:52:19 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="YYzPQ/YI"; spf=pass (imf02.hostedemail.com: domain of wqu@suse.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=wqu@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721292719; a=rsa-sha256; cv=none; b=cUo9SqOtiIkK+8y/v5Gh0jM4rW4zO4RNnAvaeg4uZdzhD8dfw1z0eWSu2HO6DzafQ5drE4 tMEUUrrvwJzppVw+dHUC+uxR5brQkVI9NUOREIqOseBdGbUy4nT5qeU6aQcnFMhBDp+PfT 53VdrwAS3L/mQaBABMqVJ5Fz0e6fjfk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="YYzPQ/YI"; spf=pass (imf02.hostedemail.com: domain of wqu@suse.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=wqu@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=1721292719; 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=kTiPZ+z60DtKJfcnwPuELD+MHjU1hcMmacIvAZVTSps=; b=jb9MyEyd2YIlAqAFy5RikeEx8wRz8evBIaceJSPw3IuNT+07uZaz+tpxUmfbWdLalK0scb e8FuJa4BXHeSLEWUBRdwfB9ZigWPOgGjwKwyW8PuA4tgsFfi4FEZeP+yyswPKLpu5FSz7h LvE8tA/Q9/ZAKBDjFXo/QT+l3gBRYjM= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2eeb2d60efbso8407111fa.1 for ; Thu, 18 Jul 2024 01:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721292738; x=1721897538; darn=kvack.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=kTiPZ+z60DtKJfcnwPuELD+MHjU1hcMmacIvAZVTSps=; b=YYzPQ/YI345HHUh1yaZCzIydF/XRDVX41ugKZyk0H3Bqjp5olhqApOuC3bLXQgloUn yHRlre61n0TrU3lu/o7MSoagF7vIsUr1Z8AemwSbah3fjgP5SlrYwGQ5gxEit453B0zm 5CxzzvWjGkAkqNXgsyH8RXFw2vxOElFRKaR89ENxhWB7nRl4qawKzws2xmzHPh4JlNkv V6ClFl7Tdx472+gBInnDupWxkWPWYLN2qmr2H63ys3HKJDdmBV4dFZXVzH3b54ktFcxQ JiGCTZtVQIgRXXlVBVPzepto7t6/WfnANSO9m6dYbtk25cFgnIJYaRgd1sBkibJNiziR LfFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721292738; x=1721897538; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kTiPZ+z60DtKJfcnwPuELD+MHjU1hcMmacIvAZVTSps=; b=WRdH24D2Ool8lvpwiByDpz9A7ixupTfPgfPwSnWQqd9BD/EaVpHvQYOnxTGZW4I0li yB7b1LG6VEC4yXSPErBwwN4Ia96D5br1sozo6w4qTpbb0K9Be4PB22lKSdO9SnsBJLHJ W7lTFkbSeyqkUDIDz+hW1RSoPbXFKl8niuKIyf4v4QCalJOHBmyGZDCPTKLNlU/3T7LV p71v9D9COOD0a9CJnkb62WHTaczgWJwSzUTFmz7ryCaBMqhjexIGNl53b6H4cJhQyhB6 WHJos3BpXdIM7XSfXXP2Yhq7xmqz9M/RZAnSfku8wOGiW4nsDsL2QRH003i08RNjOsaY TiSA== X-Forwarded-Encrypted: i=1; AJvYcCWH8tDSvZItBjqNfLBOLKZxkWW2zk66oBQVaISvudeZRA441H8aPk2UVNIt/qrRkCayssRmbOwFLxEYfZlo52N9CeM= X-Gm-Message-State: AOJu0YwS2ejXdB2tKYCGBH9YxTRWHBr2WA1Rd+myTeVFDlFdvR013jbC zjcMqe0Km0VODiS6Afjn404NpHyRWPAvRtH6nJnuSmwe27wW3eyOBjuFbFqZE+w= X-Google-Smtp-Source: AGHT+IEKoEibRJdMaexuXPAxzHxwsv3/AhpoOjO3TsAbh/uEeOkHfPag6XFMXpu7pQMRDCuN9B2huw== X-Received: by 2002:a2e:a541:0:b0:2ee:7dfe:d99c with SMTP id 38308e7fff4ca-2ef05d2ed3fmr14146781fa.31.1721292738013; Thu, 18 Jul 2024 01:52:18 -0700 (PDT) Received: from ?IPV6:2403:580d:fda1::299? (2403-580d-fda1--299.ip6.aussiebb.net. [2403:580d:fda1::299]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fc5ef02826sm9172165ad.67.2024.07.18.01.52.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jul 2024 01:52:17 -0700 (PDT) Message-ID: Date: Thu, 18 Jul 2024 18:22:11 +0930 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] mm: skip memcg for certain address space To: Michal Hocko 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 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> Content-Language: en-US From: Qu Wenruo Autocrypt: addr=wqu@suse.com; keydata= xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB AAHNGFF1IFdlbnJ1byA8d3F1QHN1c2UuY29tPsLAlAQTAQgAPgIbAwULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJjTSJVBQkNOgemAAoJEMI9kfOh Jf6oapEH/3r/xcalNXMvyRODoprkDraOPbCnULLPNwwp4wLP0/nKXvAlhvRbDpyx1+Ht/3gW p+Klw+S9zBQemxu+6v5nX8zny8l7Q6nAM5InkLaD7U5OLRgJ0O1MNr/UTODIEVx3uzD2X6MR ECMigQxu9c3XKSELXVjTJYgRrEo8o2qb7xoInk4mlleji2rRrqBh1rS0pEexImWphJi+Xgp3 dxRGHsNGEbJ5+9yK9Nc5r67EYG4bwm+06yVT8aQS58ZI22C/UeJpPwcsYrdABcisd7dddj4Q RhWiO4Iy5MTGUD7PdfIkQ40iRcQzVEL1BeidP8v8C4LVGmk4vD1wF6xTjQRKfXHOwE0EWdWB rwEIAKpT62HgSzL9zwGe+WIUCMB+nOEjXAfvoUPUwk+YCEDcOdfkkM5FyBoJs8TCEuPXGXBO Cl5P5B8OYYnkHkGWutAVlUTV8KESOIm/KJIA7jJA+Ss9VhMjtePfgWexw+P8itFRSRrrwyUf E+0WcAevblUi45LjWWZgpg3A80tHP0iToOZ5MbdYk7YFBE29cDSleskfV80ZKxFv6koQocq0 vXzTfHvXNDELAuH7Ms/WJcdUzmPyBf3Oq6mKBBH8J6XZc9LjjNZwNbyvsHSrV5bgmu/THX2n g/3be+iqf6OggCiy3I1NSMJ5KtR0q2H2Nx2Vqb1fYPOID8McMV9Ll6rh8S8AEQEAAcLAfAQY AQgAJgIbDBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJjTSJuBQkNOge/AAoJEMI9kfOhJf6o rq8H/3LJmWxL6KO2y/BgOMYDZaFWE3TtdrlIEG8YIDJzIYbNIyQ4lw61RR+0P4APKstsu5VJ 9E3WR7vfxSiOmHCRIWPi32xwbkD5TwaA5m2uVg6xjb5wbdHm+OhdSBcw/fsg19aHQpsmh1/Q bjzGi56yfTxxt9R2WmFIxe6MIDzLlNw3JG42/ark2LOXywqFRnOHgFqxygoMKEG7OcGy5wJM AavA+Abj+6XoedYTwOKkwq+RX2hvXElLZbhYlE+npB1WsFYn1wJ22lHoZsuJCLba5lehI+// ShSsZT5Tlfgi92e9P7y+I/OzMvnBezAll+p/Ly2YczznKM5tV0gboCWeusM= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: gnkbwfxefhtrxddfcndfwxyb7zn8tm8f X-Rspamd-Queue-Id: EE91380012 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721292739-651994 X-HE-Meta: U2FsdGVkX18OSOemtwsLWHu6B2Flc7j5nBlpVzkSYWl7IssGVeEyYwwuXsRiITRPLuhWiz7JtYnae6NFvPDzLqH72RhwhD+joxZS0w4MtW7TxR7s/MGbEpLVVpxHkJ2ShkKmwfiYsC9wqjfym2t23qPZeRh+BiGb1T8a2rMt3DoHdvRt0+RMiVsNPXlfVaBbYwTQ+fcJt+SzvTGORC9DUkZ4F7ZJAFzo8o6vjBwaEtWlmRKgniZ+MBZTSftk4c4G2Bj3YuCMMwgT9poOLHSHuh7y0o6+y6SoYO5HE4WdZUyhlieSoaboSL7H2E5wXbewcy5kJoFMNo726QdQX4Q6raUCzoPNPNd7fZuADFmkIXaaHBkqeV64o2Q0r5+70FpPuzNa/MR+F6aaCUO5wg+jqtR/j2unHq9y/UitcytunP/msYrWkVmQWjkfBqDwlwb1YpTWxhonn8h5kZuj2Gm2fCF6CUhMhIpWVFSldIU4sHoHbwhnua7SKm0mfZ8Lspf4F1CYJGClEVOUthnClchhBWIUg2/7Xv3VXJ0VsSgRC4dven/LH9yJEEaJrtPevMmqxWoVtYoI0zrDd5FCCcMoKXAv3QpwGyQiZTk8tHXEfHwo9N8ZC/RCU7Bhj5ufQSCwvf9mNwhfc1FZHVjX9vMs4jJ3hdmyQ+MDIM2LLYd0/Djf3wdog9ghO1GYCezJuLIAxu7Di377/MRINV5zhTEjslqO+6b1sbvq2CXK435yQItvRO42ofIbhwy5Qi16gJ3L57IXU2WezvlnoPL/tR0hYz4zP860YYX11tAwi2YAWHN93VwzfrtTRguGPiRmvYwcSx7ffXq5B9H2B4YUqLbTXUDuWom2Q/4SW7Qg6g7z5Q9BxC++ICOFuQVMDIAYdkWXWW4YsAoWM1zciJqhJj/5G1Qr9wshuR+JrmoqvKLrfaXOidHMTbEHwuMGm4L6jWKLloYituS3snG3Upn8oBE rbaJsyOA uFQKfxlJH2LiHTaKyT84NpuCckiFExpnV7+1QAruTK094GHu5dLF5fGWClt1Ks6Xt39ceO/VS5iyBFzC0ck5sMdoXbDNUfGRou5XHbqwIAZIMM0H7kuBUcp6AcJBytR47Mc0/4XnlNAqH+Gml8HHoJBm348jSo1etA1Bn0+g5pRtSxnXhgn8jjgbcZ/7NbRWGV3ub1yyqa+IZPwr2dTko4yn+Ci2Z/tt0Wqge2y40CDRE503WDdhnFJNWYpe228DwEAnVeWdGIo59c8q7MwsS5dn0maQO6wSzcrsV6UNSAnQ2jIc= 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: 在 2024/7/18 17:39, Michal Hocko 写道: > 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. By the caller, did you mean the user space program who triggered the filesystem operations? Then it's too hard to determine. Almost all operations of btrfs involves its metadata, from the basic read/write, even to some endio functions (delayed into workqueue, like verify the data against its csum). > 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. > And for root cgroup I guess it means we will have no memory limits or whatever, and filemap_add_folio() should always success (except real -ENOMEM situations or -EEXIST error btrfs would handle)? Then it looks like a good solution at least from the respective of btrfs. Thanks, Qu