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 F09B4C47077 for ; Tue, 16 Jan 2024 14:51:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88EB96B0083; Tue, 16 Jan 2024 09:51:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 83E7B6B0085; Tue, 16 Jan 2024 09:51:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72D826B0087; Tue, 16 Jan 2024 09:51:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 634136B0083 for ; Tue, 16 Jan 2024 09:51:25 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2E9A41605A9 for ; Tue, 16 Jan 2024 14:51:25 +0000 (UTC) X-FDA: 81685462530.10.4007882 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 5749E16001A for ; Tue, 16 Jan 2024 14:51:21 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TN4d9eK3; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705416683; a=rsa-sha256; cv=none; b=A/aLyMRNVvmHeKcKtqrAnubdEeXUMx+WdDR/XglJtLotlBxPSJS+EP1sFdJqKYnRILP9Zz d/e8D+J4+G6TrU9rfAOJ/ReHXSFCxdXDAS3aYu3Lg3E3w0gN/GDtfYmcoXrlh8bWxSolo9 7sdvoAz9D0rx8YQs8Lt6FMEpuzZMtnQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TN4d9eK3; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705416683; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Wo2ZeZzHWLKlJAoyYAf4I5Hw6H08g/lJvj5SWxry/6I=; b=KLg11nUTQzYMiqcqykKSAI/FWlgCpEF4FOVXYSwefyBOwnyPRA0dw7uqOkjLl+ApYwzF7S lJdweXe0z/O9BI8Hye1aJXHXnXWFy6h23UEG1Oyb5SRdK808tyqL4yI6Fxfyrr9CgOGk9l HFb4YTEpaKUJWsWGojlDhu53rCI6Dkg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Wo2ZeZzHWLKlJAoyYAf4I5Hw6H08g/lJvj5SWxry/6I=; b=TN4d9eK3eibLenJuYp8+drrwvC 2Qfn400Q7FkqyxnyUf/mn2VxsLmkOHhWen4/grB9bSWT7cXHS73tbrcJlJBDJpVcJVdb+Iuo7YQkN yS2XiLfdCz6TTDGzaxQC0jQKpArEgjk0aJEic+GwPOfjFUiuh5KBo2+/kwyIB2D5Jp0FIj+YLj762 nJTPM2dvMaH4xPpsItTkXPo3VqYfXsUahUIDjmIZqank7qlxTb2mmbSQj5L+9XIzQQXFkfQ48IXQu 02S5FAs1NcrKwZVSCAbtK/kivgzfl7jSjMRYrF8/Wp53msfJL59BN1UzJn/ncA8KdHAvCdArnLNJT TDMH/klg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rPkmX-00DJEv-IU; Tue, 16 Jan 2024 14:51:13 +0000 Date: Tue, 16 Jan 2024 14:51:13 +0000 From: Matthew Wilcox To: Ryan Roberts Cc: Kefeng Wang , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand Subject: Re: [PATCH] mm: memory: move mem_cgroup_charge() into alloc_anon_folio() Message-ID: References: <20240116071302.2282230-1-wangkefeng.wang@huawei.com> <2c24afdf-5103-4c1b-a649-2eeed185f3fb@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c24afdf-5103-4c1b-a649-2eeed185f3fb@arm.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5749E16001A X-Stat-Signature: xxe8hyuuuki9oi5ai944zc3uzbu8zc9y X-Rspam-User: X-HE-Tag: 1705416681-237041 X-HE-Meta: U2FsdGVkX18l2az2NGwYK7SerJ8Mad83pjS5GMGM4gIAOwvYDdLs5tGNVV3KnaIDHa9GnWcpD1ZMK1is7wutN8yTgOUP7ZkVh4xJQ0CSQ3sIelhQ8xOCghGQw4EjTcFYdDTGJJTwTqzQBre4fPWzufZ/x8VKUVdNB1KWwPqSrdz2bCYmSdyRwNPUNQI7YTb18jL5PjLTMrzCeSi6TkeW5ofTOpXXeIRdFMtrAxLxJpss7WgirJH5RzwrEap9jMybbi4y45j7P6bpt6Iw4+HfrJTS08RT4tQbAoauWiCkjCWe72VDh2udXQK2jGll+cOiXDf28g8V3Zrjw+P1Me/WddR5x4twaGc8J0knWOSyoERnc2Vl37prZDLp4TteyyunEpq8D6miMa+7yFq9ItXCshl917boZrUvrs+iy+GR0bzTrbeapVVRQTxO7rVTdAXgzj5yT65TceY2rJHTwra8PXjeQzAQYVqRzgumz8Fc1bxME5jZ5yrNp6c5JIlvd41CjV8tLKYshBBbZa7Kgm+w/W2eVCC9FaaS2ulKe+DUy+3Z5ejQSC6EFE6jpGCGe9EnFPiS/M45vdzHuSwhyVtLshToiboIsUnSF66wrgvYKkKrsfuWLOyVzPXi+pVIOqICrWsoK8ApCL1DtXNqo8/JycRHIgFtYA1pirXlPsT3GHAyG2yHoa4floI0R2114JJ7fmKO0xZrz53LIv5pkPRsoBvNzDDHfbIIjW3jABePCr//8yhaFRumj5TNxX1IF0+As0Opg0LR8NV/f7CSfGX1R2OE2hwbGJCpiGLChJQ/MMW5fd05Y4TGjpcslvkP8KKQ6b0FXGSuVTbisUNGDgKnRzoSBNZVjNzyxfklE5UDH4qCojvhktje+dxeI92igtOZ/fVGr+RNvwrTxojV+3+aIkcundPwW6guQXj3lUHvl6IAQR4iIKfz8ERtKbQszOkh/ShcJH0q5p/hVBDPNDr kdQGG6et U952rp0mFVJHQBpeNJ5D2gVbzSaNRCWECsNFdIps3TPKpZi8Na/foAeLqlYTvTAplzAb7iiTZwiR0J5VgRBf2Z9oka7dxZeXMpD29oNDXrrS3rpBgqs+OA/vxwESVsVzLwyUEa8ojUaOpBUCi50eD4uy671zpsYUhWKtbQUkY26zZmosYo4NPQjIpIQ== 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 Tue, Jan 16, 2024 at 02:35:54PM +0000, Ryan Roberts wrote: > On 16/01/2024 07:13, Kefeng Wang wrote: > > In order to allocate as much as possible of large folio, move > > the mem charge into alloc_anon_folio() and try the next order > > if mem_cgroup_charge() fails, also we change the GFP_KERNEL > > to gfp to be consistent with PMD THP. > > I agree that changing gfp gives you consistency. But it's not entirely clear to > me why THP should use one set of flags for this case, and since pages another. > Why does this difference exist? I think it needs to be spelled out much better in the changelog. Here's my attempt at explaining why we might want this change. 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. ... I remain not-an-expert in memcg and anonymous memory and welcome improvements to that text.