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 38CFDC4725D for ; Fri, 19 Jan 2024 08:00:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F4006B0082; Fri, 19 Jan 2024 03:00:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A3196B0085; Fri, 19 Jan 2024 03:00:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56AA66B0087; Fri, 19 Jan 2024 03:00:50 -0500 (EST) 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 484666B0082 for ; Fri, 19 Jan 2024 03:00:50 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C64C240C8C for ; Fri, 19 Jan 2024 08:00:49 +0000 (UTC) X-FDA: 81695314218.13.CBEC5A7 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf18.hostedemail.com (Postfix) with ESMTP id 8B40F1C000E for ; Fri, 19 Jan 2024 08:00:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="Tl/co0SH"; dkim=pass header.d=suse.com header.s=susede1 header.b="Tl/co0SH"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705651247; 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=Bn5ufnHpA6Z9dfznXpVhdImFXiNotqxspeRNBGa/t/s=; b=3w0bSWhvjqJWsjQ1k0JtqaWZFro2B1X1Hd6r+iznzdCKp3j8pMUHEoS95xJpXjGSX4SlA+ lFQwkE7hvKozJJiahmpI8VNOapXhtEYzRVKkIl2jLUQuITnNpYR9xgc6TRm0ppH1L4StXm O+Lqeeeo0HrjqYlyhYVb45tnRITTGs4= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="Tl/co0SH"; dkim=pass header.d=suse.com header.s=susede1 header.b="Tl/co0SH"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705651247; a=rsa-sha256; cv=none; b=B/VnrOKJeuzbSvy037JI3msAfW+JzuKSrbNTXCQU13DzlGHNrWtp/JQSa+blfCEfgJDZas 7cPG4xhNfPa5s3Bm87LOfARQzE16ClTXIfvY1TqhprLeE//MUMFpQaFQHHI1REleZIr5SU l8V4vkdmSxu0AFp1N2mU8jgPmhZM20Q= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A6A802203C; Fri, 19 Jan 2024 08:00:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1705651244; h=from:from:reply-to: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; bh=Bn5ufnHpA6Z9dfznXpVhdImFXiNotqxspeRNBGa/t/s=; b=Tl/co0SHQk5Ek/hRvLDHlUdr7CyoF1wFwgMIQoYkkEHLVCPtFcCVdSxgvyJzgue3nf2WwE n2VTmEXZWd19esIA+6d6l+IuZ68tHGqH0N3Q2LvsEHMgOD4u1pRaSoYfIfzzGqIG0Z7kTM NbcHHeQVGPOMxTf2Wx0/w2v7NQqO9xs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1705651244; h=from:from:reply-to: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; bh=Bn5ufnHpA6Z9dfznXpVhdImFXiNotqxspeRNBGa/t/s=; b=Tl/co0SHQk5Ek/hRvLDHlUdr7CyoF1wFwgMIQoYkkEHLVCPtFcCVdSxgvyJzgue3nf2WwE n2VTmEXZWd19esIA+6d6l+IuZ68tHGqH0N3Q2LvsEHMgOD4u1pRaSoYfIfzzGqIG0Z7kTM NbcHHeQVGPOMxTf2Wx0/w2v7NQqO9xs= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8430E1388C; Fri, 19 Jan 2024 08:00:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id mMZMHSwsqmVaOQAAD6G6ig (envelope-from ); Fri, 19 Jan 2024 08:00:44 +0000 Date: Fri, 19 Jan 2024 09:00:43 +0100 From: Michal Hocko To: Kefeng Wang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, Matthew Wilcox , David Hildenbrand Subject: Re: [PATCH v2] mm: memory: move mem_cgroup_charge() into alloc_anon_folio() Message-ID: References: <20240117103954.2756050-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8B40F1C000E X-Stat-Signature: w1haiz9313petfmgqaiygkzhfqm79qjy X-HE-Tag: 1705651246-435544 X-HE-Meta: U2FsdGVkX19ARKrKn/3kzskp4mpGKA05+flxmdZ7BhZnfHwOzgxpgDBPaFM2WHrd7NMw4lRMtCgHQXbfMopZ8iZMnaiVuU32KIUyHyG97oE92EiXxwees20oahb2UHa2LlaK71e+idzJPq7Q5ek0Z0o7wd46mC8BlPpGM/up/yuAdXQnZ+ONUcX/2rE/5UDtYWNQd5ZViIbYlO/fUZluw5TXChmFaKWDde/LnLbaXAZkJs2Xz9Bv+ozV2+8+IN0ZQdE/X8D3112LuBMNLOg3pAhluGivCGcWeVrnu6Eq/DsV+HaCwsSbBEooa7PSWlXAauiXNZqxxJ4RDQtHuwEJxNa5wrexPiCuvNF+CN3NViNyR2zuXvusvmKbMiilmjg0MFW9Fblf2AhlMFL0hdTvcmwRlp/uJwHMGf9l8hp7LGJRm1PQ+su46pmAlY1W5bo6fj3KR5UyGRON+XlDveGn1Y81Pj6ZiT9UMsUAKBpMfeKg+lq2BzmAgLpYHhuRtQhkuCWbNEM604Xp7XYftVRiB26lJYcR+Jy2NAfiNH4Iy+RdBkcRHsNV4vO5U3RyPnPcMeBlpBZcdg+l9BmSjCfZpSMJkLBuMivTlhlNnhwKeNhzh+2H7Xatx3uHx3n4HTY9sdh66VP/L29S9ps7yqF+zRIc88UHFbOOKgQI1sj9VT+LSChwCdo+9bVxHX1XSEk83srYyPSJ5AfgHOe/AYf8cin6FI06UcYGfL5c6aaieC30Sv/sFAKjhSoFHkYV+kDALku782aHfSTsesaHGH1AtkHpEf1aifUaGhkBm3OVyFinm5047X6hghVBi4nfmxq9ZnhjMf0IwpTp6MSwtolqLYp5ZCVUyqb2lx+Xk+Jk62STOFZ5sv/yBguADFJQ78FOA5ksOPS+vWKKbasnQJddY7t2bxm/JM/zDgfUzZeKRaFRmXAswQeb7N+93zpOYW0NwDtG1jXqYYRNcVH0CU8 0ds3boOi XfpghaRVc7BgodukKJjNBrL7PmG7nHdKVXgjAd/OWCDNlBdM8Nh16oZ162XeZgS9mV2/L6wRXnTzoeGIsFcdgRl/jGvKyGVFDgutLTJJGILYNyQxka9XRrGujVxs0e1tx+mqsWTlgBrJJOOu+0BP6KRcxkHSnHdMzPbjIrg6MwhswaKl472RX4TR4cTDMRgQaGYbvEg2fbHbpgm0HqNHjLhqB9xpSIeaAifJGiNIoeDwHyZyvkoDGdMJxsP9YWWMI1L4F0kr8QixXo4U= 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 Fri 19-01-24 10:05:15, Kefeng Wang wrote: > > > On 2024/1/18 23:59, Michal Hocko wrote: > > On Wed 17-01-24 18:39:54, Kefeng Wang wrote: > > > mem_cgroup_charge() uses the GFP flags in a fairly sophisticated way. > > > In addition to checking gfpflags_allow_blocking(), it pays attention > > > to __GFP_NORETRY and __GFP_RETRY_MAYFAIL to ensure that processes within > > > this memcg do not exceed their quotas. Using the same GFP flags ensures > > > that we handle large anonymous folios correctly, including falling back > > > to smaller orders when there is plenty of memory available in the system > > > but this memcg is close to its limits. > > > > The changelog is not really clear in the actual problem you are trying > > to fix. Is this pure consistency fix or have you actually seen any > > misbehavior. From the patch I suspect you are interested in THPs much > > more than regular order-0 pages because those are GFP_KERNEL like when > > it comes to charging. THPs have a variety of options on how aggressive > > the allocation should try. From that perspective NORETRY and > > RETRY_MAYFAIL are not all that interesting because costly allocations > > (which THPs are) already do imply MAYFAIL and NORETRY. > > I don't meet actual issue, it founds from code inspection. > > mTHP is introduced by Ryan（19eaf44954df "mm: thp: support allocation of > anonymous multi-size THP")，so we have similar check for mTHP like PMD THP > in alloc_anon_folio(), it will try to allocate large order folio below > PMD_ORDER, and fallback to order-0 folio if fails, meanwhile, > it get GFP flags from vma_thp_gfp_mask() according to user configuration > like PMD THP allocation, so > > 1) the memory charge failure check should be moved into fallback > logical, because it will make us to allocated as much as possible large > order folio, although the memcg's memory usage is close to its limits. > > 2) using seem GFP flags for allocate/mem charge, be consistent with PMD > THP firstly, in addition, according to GFP flag returned for > vma_thp_gfp_mask(), GFP_TRANSHUGE_LIGHT could make us skip direct reclaim, > _GFP_NORETRY will make us skip mem_cgroup_oom and won't kill > any progress from large order folio charging. OK, makes sense. Please turn that into the changelog. > > GFP_TRANSHUGE_LIGHT is more interesting though because those do not dive > > into the direct reclaim at all. With the current code they will reclaim > > charges to free up the space for the allocated THP page and that defeats > > the light mode. I have a vague recollection of preparing a patch to > > We are interesting to GFP_TRANSHUGE_LIGHT and _GFP_NORETRY as mentioned > above. if mTHP can be smaller than COSTLY_ORDER then you are correct and NORETRY makes a difference. Please mention that in the changelog as well. Thanks! -- Michal Hocko SUSE Labs