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 5D678C47077 for ; Wed, 17 Jan 2024 01:34:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5B3A6B0072; Tue, 16 Jan 2024 20:34:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A0BCD6B0087; Tue, 16 Jan 2024 20:34:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FA996B0089; Tue, 16 Jan 2024 20:34:10 -0500 (EST) 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 80D9E6B0072 for ; Tue, 16 Jan 2024 20:34:10 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4B3D380AEC for ; Wed, 17 Jan 2024 01:34:10 +0000 (UTC) X-FDA: 81687082260.13.7D5E17C Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf05.hostedemail.com (Postfix) with ESMTP id E5A2F10000D for ; Wed, 17 Jan 2024 01:34:06 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf05.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705455248; 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; bh=6bAgugYhRdwVoAUFTjeIPrvHmoER7FzehrfCAqyLJ9A=; b=42Ryzf+L8ma4yPbtsYykELmJ5CDnrcjYjzObRYPf93y2d7UrbKcbT71ytcMP8TWrKw251o AEvhJFrGaPewscaZKFemfQ5pGSRTnusrJWg2MkYUXs4uo47IJOAtzQl+aZLsO8Qh9fyUPO vKi27ry7/2mbq2zOiTB0fHcIwEJy0Gs= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf05.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705455248; a=rsa-sha256; cv=none; b=ZxHho1Tx1HhQ2uQXUdnSbk0QT+iozo8oNRVRefJFm/1gW9ynko2Wo8YwI4ZMueJ8eKO4m2 FY/ksogENlsaVzuwpyh6rnmaGRgN4vKyJyOHrwFMGuHaoVFd9ruXWOpWQHRXcvHV3y0FBR xKcgdPbPliSRVcz73JRqlgXAq9FLWjM= Received: from mail.maildlp.com (unknown [172.19.88.234]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4TF7fH6c46z1V48D; Wed, 17 Jan 2024 09:32:23 +0800 (CST) Received: from dggpemm100001.china.huawei.com (unknown [7.185.36.93]) by mail.maildlp.com (Postfix) with ESMTPS id 13B0D140113; Wed, 17 Jan 2024 09:34:02 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 17 Jan 2024 09:34:01 +0800 Message-ID: <49ee43cd-f356-4441-ba95-4ac81ef98bb2@huawei.com> Date: Wed, 17 Jan 2024 09:34:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: memory: move mem_cgroup_charge() into alloc_anon_folio() Content-Language: en-US To: Ryan Roberts , Matthew Wilcox CC: Andrew Morton , , , David Hildenbrand References: <20240116071302.2282230-1-wangkefeng.wang@huawei.com> <2c24afdf-5103-4c1b-a649-2eeed185f3fb@arm.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm100001.china.huawei.com (7.185.36.93) X-Rspamd-Queue-Id: E5A2F10000D X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: st1huo3r16it534jry7p8j1wejrhd8n3 X-HE-Tag: 1705455246-625549 X-HE-Meta: U2FsdGVkX198i93RmNg/+C7zmHgo4oA7992ZDA3YFW4HlBmo87ImJ7VfpsIneH/lNmXQIvS2LFsja2Oq/v09iad3yV11Vx5qqWmJzR99JOp0Pw7M8Xepbvv+FAn+mOz0w/repUP768KFLNnJJHtA8ELH0AwQ4VMNv3xMjTrX1jBFfpRsownhNH1rUQK2xzWOOMRr6P1RjioDZos//Y5sXqEwXiFpaVkjme0I7820zsJXwlFabE3PQJkSiKzIwteQjmx3E3BDN9Auz9zTYJAuUAJpSHJb+TiGvvSZ0jPMfqZcV1MwyDiJxFzuY2E/PC7gsrAorXr5LY9ZkIWlv7WxPw+drHaixPtWf1UMW4LZFWDbh4kxCW3LCwu9P0NAGRwYpdnHol/dj8Hl+Krsmxu0lVQBnocttjXeYTnYq2I9MFHr2MtUXVten0+X71N/M9Z+2b0+9iBqNTqn4Sn4CLyPX+jRCpwKB9SJKOChBaItTcL165uGniG4MsXTMhVowFKxh/d7v4iHIWQWZkcKTLwQXQQ/tIRV6fH/7tzmG1Ukp+sdsjhoUj7eRq6O7xCpqiIWw7/R+qBqOVno7yfm90As8U9XRvsGsuBLhQv4tLtxa0VFst9i0l50ftz+q7qABQBnIoRXFMSBBmWJrxeOUz0FpDP9yGh9tdtbP43qIQTEXsA1E5RhnnT9P8xZxnZk7uQ0AajWETa9TrMcYf8h0Z+h+eLaIISZq4vz6n63P0jCe39EV8TS9LnG8UHwY7AvWKIX0y6sCO0uLCG0nM2oVL9O4Gfum+O/42Yb2w6QGjaNyLwBi1V9zmdonabyEZgSVr+U8RABcSSGUVd+9z5b842ZKqabZ3A1oqwnXdpJHnAY/f3hyaSsnqj+RKmRRG/LArvz6HRTWcy2cv62eOioTxvmS9zSVg95SGeDRC4YRds/K4mRP71q5YwbNqHUYO2ZY+g90iPXPTLBk9QTVN5YiYl nQu3oEvp Wy87qh0Q7giLtQQPBOb1z3bBizuykc0tSKIma7ivnxMW94tGj3fd0U740B3bU4HGNYQGHU2p76sPwXIUh0w2x1/KlTSzudpMN4BM3JzArmd9f1YLkvn5Yl0gKjlkwMaCs/z2zXgATVSd532cMFY99K2B0UOYb1ARHqECFY5AOEHl3nN5CYGr6eAN8e4kZWfvK4Vho93/Zy+WRnnwpbjIZm1E2yg== 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 2024/1/16 23:07, Ryan Roberts wrote: > On 16/01/2024 14:51, Matthew Wilcox wrote: >> 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. > > Thanks for the explanation. Please add to the commit log. Thanks, it is much better, will update, a similar change in THP, see commit 3b3636924dfe "mm, memcg: sync allocation and memcg charge gfp flags for THP". > > Essentially you are saying that previously, all mTHP allocations would cause > reclaim from the memcg if the allocation caused the quota to be used up. But > with this change, it might now avoid that reclaim and just OOM, if the flags are > as such? So then we retry with the next lowest available size. Makes sense! > With correct GFP, we could get less reclaim and faster fallabck to next order, that's what I want too. > >> >> ... I remain not-an-expert in memcg and anonymous memory and welcome >> improvements to that text. > > Me too...