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 92635C3DA49 for ; Thu, 18 Jul 2024 07:57:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25C616B0098; Thu, 18 Jul 2024 03:57:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20C426B0099; Thu, 18 Jul 2024 03:57:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D4056B009A; Thu, 18 Jul 2024 03:57:17 -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 E1A486B0098 for ; Thu, 18 Jul 2024 03:57:16 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CD3FF4083C for ; Thu, 18 Jul 2024 07:57:15 +0000 (UTC) X-FDA: 82352118030.20.296C23D Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf03.hostedemail.com (Postfix) with ESMTP id C0DBF20007 for ; Thu, 18 Jul 2024 07:57:13 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="ZTPt/dqG"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of wqu@suse.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=wqu@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721289400; a=rsa-sha256; cv=none; b=ZzpsVtdzFJcPdRf2sWouWwxfoDKDVOyIFc6DA7FqzwRP1yS7RDu81MLQH1Ng1G4mCJRjmT Is3yuWwhVOwfuFk+8L0XNilIQaDVFCz/1EdBEtCE5lD3uNdhcfGiEhFDqNeAO9PVQCmPdO ahRbJucIqh+Dvr6pFXB0x4Kf2ODeoyg= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="ZTPt/dqG"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of wqu@suse.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=wqu@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721289400; 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=Ryf/L9F3W+yS7sE2LI6OBmRUvcJA5RPJZdjnYSn/YoA=; b=DSYzqdtjayQKBXb5iIGMxbmL1qjTo4qSyCvnCNFqP3FvHxeFGJme3n4S11rTQB2s1ZScFw yXGKf2ouzJO/395dNiqXmx/tTaeIbbwCZple11Xhow64uC0mex+S5737qWsqFLYnbxhw3w xS94psGkHq1OWkc1tQcKsfiWpJ+8CWI= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2eebc76119aso6278441fa.2 for ; Thu, 18 Jul 2024 00:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721289432; x=1721894232; 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=Ryf/L9F3W+yS7sE2LI6OBmRUvcJA5RPJZdjnYSn/YoA=; b=ZTPt/dqGuGx4hSJdqTgZw63DBjXDIvD6dAH2gZc+8054BVPMPy14q3rH/Y+9BxJfW4 RFve64IizkDs+I6UGeQwIcc0Y5GbQqf3IstGJ9R7hNpYwlL2CZjYxh4Cx0FxOZthgZg6 onUtve2dBnu0LkrP3Zk8XhpGg0u/2eO6O6rdgkhQmgJASNJBnZ1CoZbbAZ+2xTpZkTRW LEorFkKtBhSbQ/OUT60yErDuY3XByVn1blnZNWwki2ImpoqpILPgFlmj0tOkFTPRfblw jTEQTVnh/D5xfvnQ1hh5doD9DcFArg7oeJ03xy0Um6q4ZpMMBBbG6c51NeZWGxMizKFi Am8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721289432; x=1721894232; 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=Ryf/L9F3W+yS7sE2LI6OBmRUvcJA5RPJZdjnYSn/YoA=; b=RCJtnBm+m27Q06QS3IEnOwTrWgVpqaghtBhL2Wv4gTidbU0AVUq8xV60FKzrrKmZp0 ND11YfQ8a5goV1NbT8cu1R+h5kxSbNKu5jGs/ASi0EvEFIY76AkdUr/a3KWmxraOO0XJ g+BqpZ2JFPhMqUpNusgwQeAlN20cUOeW8gev95elzKKBvIRLKF+m5jlRLri5/Mj51mZK b8+r1L8kxiqbMmEt7u4mrb2fPeBivSTf4CwF9aX3PA07QjNnA10/sgMeSJYjWXREAfU5 lVgsNKfyehztJtaEoOLgl8sEpdbZ77/AT9z0OIBjarLOwBcUortd3/rhevurU1nOAhvi zX+Q== X-Forwarded-Encrypted: i=1; AJvYcCU7grqF/x8bt8IfO+T0YcdWaKfSbGKmpUbJM9pWMxRto81M1w6wC84NH171v64VZz3nubWkrK/R+xlQFp94zsZc/9s= X-Gm-Message-State: AOJu0YxAsuI1483wAteT6reUNiLQ1Vu7irwlioy9UaokKxk2nTUjU/rc eiPdpACxxWdOeth0PlVOX+lTOTGpxfrnLvnC0QH2HBvqcBfzLc9Lqco/uHzHdtcIXxhYxqYmuIW kbkU= X-Google-Smtp-Source: AGHT+IEQZF07rHCNHOIAn/kygtiNr2VBjTyAwR8GmB+YwDBsRxlbRFz1ItA3TV5u6JgIyFN42ZARwg== X-Received: by 2002:a2e:8185:0:b0:2ee:9521:1436 with SMTP id 38308e7fff4ca-2ef05ca1b4cmr10708341fa.28.1721289431871; Thu, 18 Jul 2024 00:57:11 -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 98e67ed59e1d1-2cb77541bd2sm24111a91.53.2024.07.18.00.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jul 2024 00:57:11 -0700 (PDT) Message-ID: <304fdaa9-81d8-40ae-adde-d1e91b47b4c0@suse.com> Date: Thu, 18 Jul 2024 17:27:05 +0930 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] mm: skip memcg for certain address space To: Michal Hocko , "Vlastimil Babka (SUSE)" Cc: 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> 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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C0DBF20007 X-Stat-Signature: f7dqkkd1krhu1s48x7fdnotp1w3tq1d6 X-Rspam-User: X-HE-Tag: 1721289433-903396 X-HE-Meta: U2FsdGVkX1/ofe5zW/9xagAZ/CsKrv/Ezgag9iv/uEtvKDqO9snlIfLCa9+XTCp1FiesxsprleeqNQvcfvcUJ2ZFIdpzA47LFKzXeoTM5gLMTgfBTIgW2yZeIZIUGxzlNs3vy6hcpHB+v0hfCsSsKOnfs8kTNAoRTWCf5Q4LEnf1lHITO04tzri5W+9OOm3YoubfTZMFkWpOtZeElZ3deVLvBgJUF+d+H/WPua2U6BtVGNEYHJDOgf/wuoXYSjNRXX2a3ekkQgSu/5r5cKa8FzPD8DkQvaOM8ULPY4kNQ8mtF61U5XkN0tA38Ls7RaEa8jJQBtjMElPpNdmYAnbT5zgJZnZB2zpJJp7PJ0Kb9zrsnNk/ZBGl+vTKvU/69uYEojiCqvA1/Ff51GRb3rPvWUQm2UZikr74HJswVGMG+gwp3uqryyYiG9C6A7zKmhno2eeVkzddGCRULojggMITqYZwUx3xB49pCHBh1pbOFtp7OdoU/fGKgdGz2CXqXbdM97C5d1+rwSDQmi7LkP4x+H2PfuSRuUDb7YjLI/C0FCprUvaFjQXHcAS6hz7130fDu7E/lNxv5uy4yGuVDn0EHlHY4tQ3tCVuvHcYV3Xm2hLeSCy/0ZntMaWdJuHLlY0NUNZJEJQ4fjFfR1/90Kuwe7OS8+M9a4F2B5TfymwRxaUOXuw/5naNiKc9AIEZSEczPqgCo9xLsPfcGvGcef+lkSN9JEYsg30HPMmeV3/sjwcIu3kEb/CHAnsCk5GiUDQS832FjuhIR6m+CSDw+PEzTyQO9z6R9wynBfsWYOIG9msFL0h/ltpLpgJu/1w9x9DYHf2URNlGtvANXgaAqXxQ+lw2bDsEH9g8fstI/TE1m8Po14kamo2UwtleO+zEmusGDhK2gKjDLj0yjoop8OH0m2/BbTBBGOhz3pPgXetTSgGF+bo6ZNkQ9IYwxcnz+BlkKxArgEWGtlfWhE/9OEu mS6dFwqN xHgMkGIUqAyJ+jh1q10/wFDzguSxVNvFWmWMqAnEBHpFz9Z28iJ1SuDAvdPzhGcuUAowuEiAj3CwEOiH0WUdGSEJqK6WCddcc9xoZyAgA2yLJPlewRb8Q+gBM/TRst73C+OEs9vLjn4Y1QAA3u6dBl24OhCJPhpnfbsbEimB7Xrf3SP9FpUd47bk+BWlV72QhNCuvTGMuxsxki/JgBacSMk+unwtI5EeeyRCnZwHE+YQKiXBOFKOOcU33gwq86keK9IL/lFN7amSo/r+wgxfUDQ0VVdJqF1oOdyxQrBk9e1pTUgU= 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 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? > >>> 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. The inode is kept inside memory (btrfs_fs_info::btree_inode), it's initialized at the first mount, and released upon the last unmount. The address_space_operation() are special that it doesn't implement any read/readahead. Only write/release/invalidate/migrate functions are implemented. The read are triggered and handled all inside btrfs itself. Thanks, Qu