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 12FCDC4332F for ; Sun, 18 Dec 2022 11:22:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C0C88E0002; Sun, 18 Dec 2022 06:22:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 470358E0001; Sun, 18 Dec 2022 06:22:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 337C28E0002; Sun, 18 Dec 2022 06:22:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2103A8E0001 for ; Sun, 18 Dec 2022 06:22:30 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DF812120644 for ; Sun, 18 Dec 2022 11:22:29 +0000 (UTC) X-FDA: 80255188818.19.5F9796A Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf15.hostedemail.com (Postfix) with ESMTP id 32281A0002 for ; Sun, 18 Dec 2022 11:22:27 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GkslLBk3; spf=pass (imf15.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=42.hyeyoo@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=1671362548; 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=SrOTKZjC/4zS4jxceetN8v7HQfmBD8VQatMl0hicHKw=; b=d9K+DrkF+GIWzkBfBnwO60BRBHemx53pdGCZTKQ/L0wxlApVGaXZaKLhGq/25sp4JnSzma hF1PkpQqPw63YxG8EI28Y3br+6qybfFNJRqJ41Rnn5lo6iEh0aIkS6s6eCMxTVX35Ky2K2 bZUkP9SD1Qa7Pdff+veqZVbAnvVfih8= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GkslLBk3; spf=pass (imf15.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671362548; a=rsa-sha256; cv=none; b=rOXng9Z9yKsW/WvjEKmPeioP2IKJZNedSKTKATHRVo26swQqlSF6t5bc0hSds1Zal3e4K/ 4m/t7dzRw41o2+jQPvFNMkR+fyTd3BZ3lzF7Fy9J0s78EGBUl48hfLMad42c6MsECtM9PC sNAY7UQJOdWOWDrEL1s+Nt/hpGj5XcI= Received: by mail-pj1-f52.google.com with SMTP id fa4-20020a17090af0c400b002198d1328a0so12033394pjb.0 for ; Sun, 18 Dec 2022 03:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SrOTKZjC/4zS4jxceetN8v7HQfmBD8VQatMl0hicHKw=; b=GkslLBk3FMjpo7K57qfwE5dItnfzMc1PQrBTvxVNS2Kz15WSFtzLNI4vxU22VbbFvs enQ5hdNkXy7h7UlCEFC3z2XXoBrEE0hxDWplXVJ8VgiFLKJuC+QqmwVJikSHNDDVPfnc s0/1iE0ayZvHiX6HgbjrtHkiW2AIG4gBMfxiYDBFtjO4Zxzk/KxPDPMDDSvFAZ0H4tFF vcCowXO/4jdijMb7mvWsDylTl0xBjHrqWwr7UgjdvamRrGnacNZAMMgzp1NGj2b5X3Tc XpNZ1ZP2XqT+Jfyw7S2YpZQVGDTh8E9xsYXcXRuPXULx5bLbEyYxSgb0+aa5FHgW8vr3 waJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SrOTKZjC/4zS4jxceetN8v7HQfmBD8VQatMl0hicHKw=; b=MSizDBmvy7d4F+DtRTbu36XE+xOHNuwPqeE2uwFdR4elmSu9pCKxWXjqmr5iDPIQ6t lV+OlQRTw+9eUg28T/8pm26+YymPoEBeJLaub6AYhLLZgso8pgjk6OG8N0mbMGAip6pb h7quoFJAj+fcIoH4uZyWLAgPP49U7JUBvLjkIPKcLUiqBrBotOWgULK5g0113JpZAGp6 nZGgZmT5hLCPsyeLYodlEKO/Zm1HSfxFJaUuVFkYX9ibKUt/woFSgZPGwBiIkeKfgNZj 25/ldzXuKXCKMUxq/RYaTi3fAwzd9a15G+mbaNhO36jNekZZ0W++oNN6bzAR1+lFJAU9 HKQQ== X-Gm-Message-State: AFqh2kp76c9SN3bsPhYwkBp9NB9Zce4eGPaOQNNNkbeOofiXW8TP3f7K uu5BpvjkIIPrgfh6rv6hE0w= X-Google-Smtp-Source: AMrXdXsCtw5U4D8/eRadoueXFHwaeYbI5l5oMnLus7iHHgVExXecbYMY/SQjD148WGXMO/AsOyu9wA== X-Received: by 2002:a17:90b:11d5:b0:223:2cee:2b6c with SMTP id gv21-20020a17090b11d500b002232cee2b6cmr19519264pjb.41.1671362546961; Sun, 18 Dec 2022 03:22:26 -0800 (PST) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id w17-20020a634911000000b00477def759cbsm4283046pga.58.2022.12.18.03.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Dec 2022 03:22:26 -0800 (PST) Date: Sun, 18 Dec 2022 20:22:21 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Yafang Shao Cc: akpm@linux-foundation.org, vbabka@suse.cz, willy@infradead.org, linux-mm@kvack.org Subject: Re: [PATCH -mm 0/2] mm: page_ext: split page_ext flags Message-ID: References: <20221217105833.24851-1-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 32281A0002 X-Stat-Signature: uh3ggt6wxfxrocsojd7wfhye5t4ei8sz X-Rspam-User: X-HE-Tag: 1671362547-145038 X-HE-Meta: U2FsdGVkX1/8On/zkWNw7vgaclG+Genm+0ISTub3iszT4+Ew0RMBKb6XxwbdD4Uswv6xWaFFDeg4wZFvZFHhDqX5Qh/U3HIAlQ7gX/DjwVkHC+FGYsHfa6XpuZC4XUxYFbUhd9fQD+0qaEQ9fD+lgGa/dDdUnm2eIqUHZxHq6DDuR2dKT0TT6jLWXYOXRVapGzJ1HKyTFU5rkckP/x9l+NrAURcLn/fhD5BZc7fRoiWB1/eHRFSkA3EdkE6xemrHHDJt42hz9g8cZ8fMVO0GrjIsA6/jA4WPIPIoNY0VgJj1QOV9kEtzFJnlTQUKotp4TIOijRLik87WsyMJ8tToakRoZEl90UXz8s4YQaHMxQWGNGz5YrOwbvcqiW4k71RVvpPzX/+E/1++4fY5LzgpS95BJn+LcZG1VYFvCC3jmZWS2LnWZzja89kxqg2hpbfZWVPIO0z4B+CXxTt3NvfV4K+SLydOjPcWjZitKITOMNz/9HDdsOxl+BG7332cCwlb7QsrYopmTinYVS9t37nEy3IrvsBGUh2eidopuqOlfyM/gSdhoHNnr0IwYrMMgeVHjW5Up3pc2wN6AmXbxEF1jXiYbfJPWc2bauUevY+LY8pYUSuaO7c74/cQIatuxC1q+OzWtsQRZ7IEofu0i3QTOY9FHw4gwjMQ6t/QCNdKwSqJt+DV2P656T8q6q6fbiR7oKiI6VAVVDocaY/hL8sr7BejwfAqPV6F1neKZmQmEAB0L8I7DCSW//WMaeencKRjNRFqmhtrBzymu87Lqemz4l0usyabL1fJTXgsKnsvlyQn7KRLVe0p9BuqmEoRd7J2Tx4vt79BuUz+x/zcmFQscfPkLY7TBD8VWaEZzhhM7MF0mqwtmzdumdpIgDviIxoAab37nyw1owDNqUQaBhIP4RpnFzMXxIlgzzRGuB9sOzCxVl6RSg/19HpmX72kuNMa43xls2uKE1ZSYWwoHFV Bunpxk99 UQcTu0pFUbJNj88eEDH8h/MkNibfbEYsAC1ITIIylxUGUC3I4A78IBaIf99e5ILxAeS5aetyXgCvBwXRAJ0rW5OUABZcVyk9Y+Mh769WDSwvE4Boubjr0QVJLkF9KIrBdzmRxJ94nI5INOx154hF9UKgwHNFeNkUNVHL5wGaMq0/CKjc4WQZZRPezxHbct471wxY7UVJBXbLZijkBXyXmgbe773bahCi4UVl8BrhstIYB2Ic= 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 06:01:09PM +0800, Yafang Shao wrote: > 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, Hi Yafang. > > 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. this improvement doesn't make sense until we have non-debugging/memory overhead sensitive use case of page_ext. > > 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. Okay. > 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. IMHO that's gonna be quite challenging.... To get page_ext using pfn, we need array of page_ext. And in FLATMEM size of the array can be bigger than maximum allocation size supported by buddy allocator. (that's why page_ext uses early memory allocator, memblock in FLATMEM and memblock is unavailable after boot process) Why challenge page_ext if call_rcu() can solve the problem? > > 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 What kind of restrictions did you mean? > and it can be broken easily if MM guys > introduce other deferred freeing functions inside mm/. That will be a > burden for further development. No, if call_rcu() is called in BPF subsystem and if the callback just accounts memory usage & calls memory free API (like kfree()/vfree()/etc), this is not going to be burden for MM developers at all. Also, even if it is considered as burden, it can be justified because it avoids increasing memory usage. -- Thanks, Hyeonggon