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 3D876C4332F for ; Sun, 18 Dec 2022 10:01:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 747138E0002; Sun, 18 Dec 2022 05:01:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F7318E0001; Sun, 18 Dec 2022 05:01:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BE508E0002; Sun, 18 Dec 2022 05:01:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 459778E0001 for ; Sun, 18 Dec 2022 05:01:50 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0BB921A083B for ; Sun, 18 Dec 2022 10:01:50 +0000 (UTC) X-FDA: 80254985580.07.C3D227D Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by imf05.hostedemail.com (Postfix) with ESMTP id 685EE10001A for ; Sun, 18 Dec 2022 10:01:48 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mx3oR3dr; spf=pass (imf05.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671357708; a=rsa-sha256; cv=none; b=rdD5oEKcSJ2agmHy61MLfl9zMo3kqIwX9/McOiEmVpWYxd3NhwcKhbo+GzQ6smeiwU+pmy +BNib0TF5BYoA4Jy5Pak7AdW5DybTzAWVRCn2ma81qQUK8mhx6U0PrfXT0oXIXG1UwynWb TWWq8jrQgh8B09wQAz6M/dWsByjj46Q= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mx3oR3dr; spf=pass (imf05.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671357708; 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=XREwoJKgSJqmolrS56gQ1GsxEY7e+lGm5OwwzQBjNqI=; b=0klinmRB4t9HDA9javnuj1U65AdZ4jgY/3vFctZNPePg8gR4KkHkBmEP4VxrEfohA5yLtF RbjcLd8RCeM/wMBnm43SsmOmR71aRAE8/fei1DcHirVGbLMVj6uZ4tSDhe4lWzNm5bhCAr 1r+PCVvKrnEYIQW8tdwtPnQkQ7f9too= Received: by mail-lj1-f171.google.com with SMTP id v11so6348684ljk.12 for ; Sun, 18 Dec 2022 02:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XREwoJKgSJqmolrS56gQ1GsxEY7e+lGm5OwwzQBjNqI=; b=mx3oR3drkUW9GzWyC3S0PIIfSPtjtM2SOS4hCQiGYnX0u+TPV3A+fMsL0+c5iP2E9t 8xgQacUL5FiowNCFVUuuG5J3VcGQGRlokE4yMkERc++REYwCl4DC0lMgfv2+R59BuqRu EOfWXbFNMtKhF4S7vEz64xzak/kXAj8flDcCsGdJNaN1GdRxlwuRr26lBDIwOtWD10Oz RA/SGjaBpgRpbW6iaptwdLNdV5s6Sk4CN1zpCbSQfTCyaBLKQYnIZN9TQyjmEw0F7L9V /A7CUVOBcTIgwZx1qdqcXXDHIO8FuCOpXZMikEMJ1cd3uaPggZXxxiVadVtI0SB844c0 CA3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XREwoJKgSJqmolrS56gQ1GsxEY7e+lGm5OwwzQBjNqI=; b=u+s8/KE6d3u+omp7W1MdlDm3nWPyJ+0IXf6MbONsDmZtkbSsCXleaFr2pGF3hgD7Lz LQPrGt/JQMCjKfuPwGQWYaIua758Rh0BlYpTZdyIJUp7+bCz0raCUq6VYTy7AsU1WwrK XQXcLCVEqzQYw+fdfLRTFi7X7GRWskuI2o+d9tf0zNM5VaVn2IaUdD4GHWP12xo2qgoz ZxLCGBVUm8B3DWEBqEjSTREfUPYTanuLerx5TG873sCCRiUnE8KjuEHXW0PUO0AoFuhy hdngFZkXOemGAdQbyIE7syN4sUJLOFvpiBMqcXGGNny7m63Gj219X4hijEGVq8t7rgpr I3og== X-Gm-Message-State: ANoB5pkhOa+Lo4npHByEYlCs0aaRMpjtLzZ1J5s0bEcNEFF33mbX8RyG jb1JN4kCj9Bml10LLogCvRhxsAK3+ThEmPZb09o= X-Google-Smtp-Source: AA0mqf4ss40SGIKtexLdEjzZLxHAnN7SY8qWbHp9o7aWsc5sYBlifUyKcPlGUmafaQc2NToUQsnkzfeQArJHtSQc70k= X-Received: by 2002:a05:651c:2042:b0:27a:3cf0:6edc with SMTP id t2-20020a05651c204200b0027a3cf06edcmr2716732ljo.475.1671357706545; Sun, 18 Dec 2022 02:01:46 -0800 (PST) MIME-Version: 1.0 References: <20221217105833.24851-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sun, 18 Dec 2022 18:01:09 +0800 Message-ID: Subject: Re: [PATCH -mm 0/2] mm: page_ext: split page_ext flags To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: akpm@linux-foundation.org, vbabka@suse.cz, willy@infradead.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 685EE10001A X-Stat-Signature: ywn76dyzkzqqzxf1m4zo6ptoz5df8erp X-HE-Tag: 1671357708-192538 X-HE-Meta: U2FsdGVkX18V9guiIEaT9w0g/KScyH9urvMKdVWBN1mvQupBVw9npCK632qJmlrHIJa8u07DpllxLH+oPRMw39N0seQACT39sQEHy27qCXggEjEYGM3PQw1pESc7FjLwh+d8MOqXosGwjMDQoIhXMaDJJHbFgJ7xMqxNPFbijHFXQu5ogcIFUew9UP3xQ+nDu9mGELBEote4zIJupYNKG/U6tv9s24EDPfCvG83nRQFWnl/9qxGPaMNVxiifBOKdYRg0ub6L3mGCZGlOj6GLkQIywFmN6ZmPOsIICoRAKNDJbMHsz6nrMkoXKFmiKKa/6r6rCgZsJ3ZehCQKcko9Wa8VMY+cd6iTRdSkAJtNiM7LYDvJZysTsG2drJqu7KaCHBpDgGIQE0lb+7QBfJ0eg6qqhxgRQQwOsDjA6wLGiuyG411HkrijCvu00UvSp9sfodSYlezdS+G9v8HhAdRjh9XFeI1Td20wn1auqafHVkWZ0/7VlKPIEHXPSmNR6CXcEEOglbxUzH9njn/qQDJIAtdXVeZVas9mZ/VCcdvE7aD/FN9udmQEoqWx3qy45wVOyhknNjZ2T0vnC69Z/NDUJDPKWaPjw6HVTj5w62TJhClp5teNDYThggeaNxBlrWsJ9FFxc4zyJjT2UvL23BZLRMPWECJMMhR9S9anBmC3r69yPeMb3KdipYw1A2yIzVvXYIXEiCwdIgW3KWbwTKZmTIxeU4ARbJOdpHP1bnHY5cfHLJ1pdLcoVNPF14Hn6CJaEuZJFuFRpmVO3whs9wKisTo8TydxJ1HFOYRmw02jMhC2s5hmYAz0zegEkpD/evECcPJBocQvugSRsw8lU40OG5kTnvNXCdB+DMIrLTfPF7wgFCZHQV9XQhBDYVcULo/ZMm/FQaDbKu1zTEg0Zd0mDTY1SXr3z4dvcfDq4bKhkrZLnj2Q5Au50Iwj/X2GPdF3041pjv1eW9iRryV7JQN Z/3tLCy9 LbbBQGSE6OQ2SsOt6SaeAU3LXb6zYX9EKS7MyWlIXfc5bIgx+uiPgeRqhJpgan5FN7SFBvtkS+fS+JobGybG8zrZjxvCatXSQ+QjnFvPuIvYODfoy34DPC7rEDivdNh2jJU+2cs8ETYvaDjYnNGtkGBorp2R66eoq8VH9B8JCFkdelmFQ/kzImo1ZjjmpJ+L/6Yzr 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: On Sun, Dec 18, 2022 at 4:08 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > On Sat, Dec 17, 2022 at 10:58:31AM +0000, Yafang Shao wrote: > > On 64bit system, page extension is for debugging purpose only currently, > > because of its overhead, in particular the memory overhead. > > > > Once a page_ext is enabled, at least it will take 0.2% of the total > > memory because of the page_ext flags, no matter this page_ext uses it or > > not. Currently this page_ext flags is only used for page_owner on 64bit > > system. So it doesn't make sense to allocate this flags for all page_ext > > by default. We'd better move it into page_owner's structure, then when > > someone wants to introduce a new page_ext which may be memory-overhead > > sensitive, it will save this unneeded overhead. > Hi Hyeonggon, > I'm still worried about the approach of using page_ext for BPF memory > accounting. > This patchset is independent of BPF memory accounting. It is just an improvement for the page_ext itself. > Let's say we finally accepted the approach of using page_ext for BPF memory > accounting, and if it's not enabled by default, you need to rebuild the kernel > when you want to check BPF memory usage. (Or make everyone bear the overhead > by enabling page_ext default for BPF memory accounting that one may not be interested) > The compile config can be enabled by default, but the static key is disabled by default. That said, the user doesn't need to rebuild the kernel. The user can pass a kernel parameter to enable or disable it. But that doesn't mean I have made a final decision to use page_ext to account for it. I will investigate if the dynamic page_ext can be introduced or not first. If we can allocate page_ext dynamically rather than allocate them at boot, the page_ext will be used in the production environment rather than for debugging purposes only, that will make it more useful. > How the problem of accounting kfree_rcu() is going? > Doesn't call_rcu() work for the problem? > I still think it's much more feasible. > I'm also investigating the call_rcu() solution. The disadvantage of call_rcu(), as I have explained in earlier replyment, is that it adds restrictions for this solution and it can be broken easily if MM guys introduce other deferred freeing functions inside mm/. That will be a burden for further development. -- Regards Yafang