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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 953ACC433E6 for ; Wed, 3 Mar 2021 16:22:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55AEB64ED7 for ; Wed, 3 Mar 2021 16:22:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1445215AbhCCQS3 convert rfc822-to-8bit (ORCPT ); Wed, 3 Mar 2021 11:18:29 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]:3460 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235049AbhCCLpa (ORCPT ); Wed, 3 Mar 2021 06:45:30 -0500 Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Dr7bp3qh5z5YCd; Wed, 3 Mar 2021 17:14:14 +0800 (CST) Received: from dggema772-chm.china.huawei.com (10.1.198.214) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.498.0; Wed, 3 Mar 2021 17:15:56 +0800 Received: from dggeme755-chm.china.huawei.com (10.3.19.101) by dggema772-chm.china.huawei.com (10.1.198.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 3 Mar 2021 17:15:55 +0800 Received: from dggeme755-chm.china.huawei.com ([10.7.64.71]) by dggeme755-chm.china.huawei.com ([10.7.64.71]) with mapi id 15.01.2106.006; Wed, 3 Mar 2021 17:15:55 +0800 From: "Zhouguanghui (OS Kernel)" To: Michal Hocko , Johannes Weiner CC: Hugh Dickins , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "Wangkefeng (OS Kernel Lab)" , "Guohanjun (Hanjun Guo)" , Dingtianhong , Chenweilong , "Xiangrui (Euler)" , Nicholas Piggin , "Kirill A. Shutemov" , Zi Yan Subject: Re: [PATCH] mm/memcg: set memcg when split pages Thread-Topic: [PATCH] mm/memcg: set memcg when split pages Thread-Index: AQHXD0TOPfGiAC+zfUG9IaYiC6n5KA== Date: Wed, 3 Mar 2021 09:15:55 +0000 Message-ID: References: <20210302013451.118701-1-zhouguanghui1@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.178.106] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2021/3/3 15:46, Michal Hocko 写道: > On Tue 02-03-21 17:56:07, Johannes Weiner wrote: >> On Tue, Mar 02, 2021 at 12:24:41PM -0800, Hugh Dickins wrote: >>> On Tue, 2 Mar 2021, Michal Hocko wrote: >>>> [Cc Johannes for awareness and fixup Nick's email] >>>> >>>> On Tue 02-03-21 01:34:51, Zhou Guanghui wrote: >>>>> When split page, the memory cgroup info recorded in first page is >>>>> not copied to tail pages. In this case, when the tail pages are >>>>> freed, the uncharge operation is not performed. As a result, the >>>>> usage of this memcg keeps increasing, and the OOM may occur. >>>>> >>>>> So, the copying of first page's memory cgroup info to tail pages >>>>> is needed when split page. >>>> >>>> I was not aware that alloc_pages_exact is used for accounted allocations >>>> but git grep told me otherwise so this is not a theoretical one. Both >>>> users (arm64 and s390 kvm) are quite recent AFAICS. split_page is also >>>> used in dma allocator but I got lost in indirection so I have no idea >>>> whether there are any users there. >>> >>> Yes, it's a bit worrying that such a low-level thing as split_page() >>> can now get caught up in memcg accounting, but I suppose that's okay. >>> >>> I feel rather strongly that whichever way it is done, THP splitting >>> and split_page() should use the same interface to memcg. >>> >>> And a look at mem_cgroup_split_huge_fixup() suggests that nowadays >>> there need to be css_get()s too - or better, a css_get_many(). >>> >>> Its #ifdef CONFIG_TRANSPARENT_HUGEPAGE should be removed, rename >>> it mem_cgroup_split_page_fixup(), and take order from caller. >> >> +1 >> >> There is already a split_page_owner() in both these places as well >> which does a similar thing. Mabye we can match that by calling it >> split_page_memcg() and having it take a nr of pages? > > Sounds good to me. > Hi, Michal, Johannes, Hugh, and Zi Yan, thank you for taking time for this. I agree, and will send v2 patches for taking these. Thanks