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 8B74BC47DAF for ; Sat, 20 Jan 2024 02:13:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 017E66B007B; Fri, 19 Jan 2024 21:13:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EE2916B007D; Fri, 19 Jan 2024 21:13:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D35D76B007E; Fri, 19 Jan 2024 21:13:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BBF526B007B for ; Fri, 19 Jan 2024 21:13:28 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9D316A2015 for ; Sat, 20 Jan 2024 02:13:28 +0000 (UTC) X-FDA: 81698067696.27.C9280BD Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf16.hostedemail.com (Postfix) with ESMTP id AA0A6180007 for ; Sat, 20 Jan 2024 02:13:25 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 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=1705716806; 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=rZjMKAWjPksVIdlo3ZUo3DI8wBSkBK6oSJZhYIarypU=; b=rw16C9ke8s+kyhdhQcOp55Ni4upzOWJElMsNZKiGM1/FqVs+dgX3/Dm+13KDVB8p+r/BGH HMgzU2VFiclAY78IrxgjoNLscvVjpnN5KNwbbitUUdA6NozsHuYMOY0/DASgwbOh5ZuHWH y/XhLJkka6iKwt3yF3M+af2+PNnx0Uo= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705716806; a=rsa-sha256; cv=none; b=2sVF+EClrZ5PDkUX6Og6iGXuJYqZfgWMXl53JopoTyCILAHAO3U+rXVtPV4gdNbvoR+L6+ VMQhY8IBKOpsJ2QAmC/C5vCH3TA4mB3tv0+ElM+RrRNKxs8tPYv8bZoVQ3O5MC025pLPcQ YkBNGK0XSHbWIgG9JXz9tShnl39/4Uk= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4TH0Pl5smRzGpn8; Sat, 20 Jan 2024 10:12:59 +0800 (CST) Received: from dggpemm100001.china.huawei.com (unknown [7.185.36.93]) by mail.maildlp.com (Postfix) with ESMTPS id D5834180017; Sat, 20 Jan 2024 10:13:20 +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; Sat, 20 Jan 2024 10:13:20 +0800 Message-ID: <2160e2ea-20af-46c4-b6b1-a974eb09b490@huawei.com> Date: Sat, 20 Jan 2024 10:13:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm: memory: move mem_cgroup_charge() into alloc_anon_folio() Content-Language: en-US To: Michal Hocko CC: Andrew Morton , , , , Matthew Wilcox , David Hildenbrand References: <20240117103954.2756050-1-wangkefeng.wang@huawei.com> <14ae628d-a9ef-42f3-9201-e90c5c88c133@huawei.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: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm100001.china.huawei.com (7.185.36.93) X-Rspam-User: X-Stat-Signature: x67q7dnef589ytdknng3ih5rz9km776o X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AA0A6180007 X-HE-Tag: 1705716805-865025 X-HE-Meta: U2FsdGVkX1/0AxhZ8y/OHDvr/M4QFRtbu5conkmrSRyCeV11Ah+JSViaTMSrorriLQ2q3H2zUKrsYTrvfBuh2rMeecCRbpYAF9IolLBs3gmib6ef0yBFw3Upzxjyzv5fqcGH3ag4tqQk5N6QloEi/auFap97AARB/6id8+N5wk0dWCtMj9iunOWT22fY8XfJMahSC/PvPnM3ILsN64vQPoY/UZxvxDVI0+MoWROV2yRcfv1AWpdnKrWqNeB6PVcgdYEKGYbHyQv9vOJvTeyWD0xhOV9GUmuBgObmyj9BizPv/WN3BM/TkqlA3Fx00qg2loLFS8gon3gDz3yM/dVf9FQTuW+N8ddB3+G75URFl1On/uvYDRdeAOk4jkoRNQ0mNt8/F5hGviSUZOH6MYZvURQTy2U54pvD5caEtTwHWqSnS4OzgxRxlqdOTd52lK0PtamY5XGZj+14t4We91l/1Av0FYOZPWtXIdCVRXPn4Le5jcPDIlxniWfqFfC8xznQET5G0Hq8Q1SyA06ILN8qPik7IxMQVzQa+v8DzUTsR7cd9IGMKr2NvPQ7er4y8vSskE6ThFP4IT60y8vB11uxK3pMDLfnxonryVRfBB31ZBDFtBHOzq7h4HdpG7OsCqxXvpjbabqWvA0Q9mYQSreiZR7gD3cMJc04f4eevtCM/xquAD7NAWa9fN7V+tgVNvghlc7UI2P+A0IDok0By7XnFFI1NkyRZuRiEFD0Nsaj6iBboY6lvJYLjtoFn2e3KfQ+ya6fPhkPrXoEYF1210ZOnmCM3GEZNnWLHOFt0zUqofnqoTxGYg7yC/Ddzqi8ql1UeLEJNhV17ygyQ9DPmMnOdzXSbqzenuW0P0H50gtzLQRMOBwG5/y5MwNH1ljoBUF5rdAqVh+20C5Zttqz/yHbHnBL+iE6VEBsRNhZWtEUen7zeJRJy1W0Hbgo2uZwSbzZgsV2mZt0S3gnWT40NCr niMIuSjh PBaOiKOABA3sd2SJMuNP3nv795Rz5Pd40vigo+0yoRlVb/OvxjewPBdsIkNH2SRi36gz5ollxY75m1Qra8KFpxYC2CKO/If9lSaU3nQO8U9RZAQvmceIOdSx4azhuHBxNOO6oiV1GIFR2byzTTEpeos+k0oCcQmVAX0Cuy6B33RqwQm2wr5jr9+ZwEZoluuKoZeD+ic8k6U9m0NXK5HbZhh+6hg== 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/19 23:46, Michal Hocko wrote: > On Fri 19-01-24 20:59:22, Kefeng Wang wrote: >>>>> 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. >>> >> >> For memory cgroup charge, _GFP_NORETRY checked to make us directly skip >> mem_cgroup_oom(), it has no concern with folio order or COSTLY_ORDER when >> check _GFP_NORETRY in try_charge_memcg(), so I think NORETRY should >> always make difference for all large order folio. > > we do not OOM on COSTLY_ORDER (see mem_cgroup_oom). So NORETRY really > makes a difference for small orders. I see what you mean, but we may describe the different processes, if GFP_TRANSHUGE | __GFP_NORETRY returned from vma_thp_gfp_mask(), then we never involved with mem_cgroup_oom(), since mem_cgroup_oom() will be skipped in try_charge_memcg(), that is what I want to say, and in this case, no oom for order < COSTLY_ORDER or order > COSTLY_ORDER. But if GFP is GFP_TRANHUGE, then we may enter mem_cgroup_oom(), and maybe oom if order < COSTLY_ORDER. So Yes, NORETRY really makes a difference for small orders.