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 55D8EC678D5 for ; Wed, 22 Feb 2023 02:38:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C4946B0074; Tue, 21 Feb 2023 21:38:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 873CF6B0075; Tue, 21 Feb 2023 21:38:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 762986B0078; Tue, 21 Feb 2023 21:38:21 -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 6767B6B0074 for ; Tue, 21 Feb 2023 21:38:21 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 29AC6140672 for ; Wed, 22 Feb 2023 02:38:21 +0000 (UTC) X-FDA: 80493368802.03.43CB0DD Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 570F180005 for ; Wed, 22 Feb 2023 02:38:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf02.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677033499; 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=/MJtiBiP40AwMd8vNU5uTZ3N/zDDyP/uL1fL9oDo8d4=; b=sa2uRPu3NwSAUeKQqL/KjmZ5DlipTZp6OmKFJID/CNKFkbsNwID1+OPuu7fkpVf+9jpyZ6 vFUOVJ1t2JFscKqAOmfIwaqTIsgh1tXHo3tLvA4h0kEmnp3rdSLYaSIdPXsYhxCcIHRDrn E1NSeuP+bRMXGOavzweVy7Ws16Ao6/c= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf02.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677033499; a=rsa-sha256; cv=none; b=H+ChkisrIA8Lh641tS+gKL65EmppJ+etb7C3UraFq7h2H6+awXMjsmageQJ8LLAxXyb3Ok 808xTdbRwk9b5l4Krkjnwyol0rotmz5VHkoDBWpz+D32Yr0A1d1T74WgOrc5tyVoXUZlxp 86cY8U8moS1b259JdKBxvPg+/eJXxLk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0VcEEUep_1677033493; Received: from 30.97.49.34(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0VcEEUep_1677033493) by smtp.aliyun-inc.com; Wed, 22 Feb 2023 10:38:14 +0800 Message-ID: <874be627-cb9e-bca6-4845-18dcd65f0f3f@linux.alibaba.com> Date: Wed, 22 Feb 2023 10:38:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [LSF/MM/BPF TOPIC] State Of The Page To: Matthew Wilcox Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org, bpf@vger.kernel.org References: <8448beac-a119-330d-a2af-fc3531bdb930@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 570F180005 X-Stat-Signature: 4168z4tnu68j8r935pxaqz78bs6y7t3b X-HE-Tag: 1677033497-514412 X-HE-Meta: U2FsdGVkX185q7w2R9QZnLtWH1wFNr70lFvSF9OgnPKArRSx9Fg8oGRmwqzvCXXETbi+qu90h3PQPxuZ77sV41yoRri0AQuT0LHglsFwKQ2MYWnZhvobfpMMU/lW56RdFLUZTg/WeK0ysDj89l+UK7FCTThi8YbHv2OpIAA4nWDFp1j6BvTgo+rId55fv0DXrySLADwFqHQkoHZcdklqWPy7N2dSNrTDJwJbmyvj683SbA0+g4Pto5bFV5ZMsRUUxIVCVrTzkMr3xgYYkI6+4MvbIMQ4YqgSl5BuCLLVe6EAR1qrUs59/p7YRCF2SrxivuG1XHOypdJjJ1NOAxZX+Igf0zd6Uy5OGLgKSomkWKUqdbCjLG4avG0yx0mUYEfuw+uSI//lIMA3DF2hvIYF3y62P0T+UR4WL3zgOz4CWtmuwGW57Upjk1sQe61wXdSVZuDhjGVQU149B6ZjN/fnj7D7uVc1fiaUkR92wgs5w3APyMD84FV5yv8fhRZb22ixMtQjVoMaQBAOgAT/MrajL1N+47QKfIloYzblBsGfjG5y3IROMpFAeOEp+Ic/1J0rBYu0FB/8szJPqrN6GU5i3yWHdZCWEA9x69OQ7PdEKWBHg6xjTjlS4WMyUuZJb4z9th94SeeaXQI+N4MQcVCqWMHD+UcbipFW6L7CreexV1Uciub0A3e4MI98gMyMWEzQovLLMUAU6UYQQoo09/lYGvqegGCtpXZ/7jwyl0iVsZEFfvdgs5KdMD+ghBULWd0jOyGKIHHIGqfKq3Nf0OBDQa8QRBlL5KeY4zj0FBwX4FFWVacyKW67Ho1RYoJNPpqEnEDTUUyUeqCC96sUJ9uNwBD9y/dW7p65/Jlio8eFIegh7RE9Zv08VYNUs3cqvK39oXqWsFykRaUcOXTZ9bibHsp7D6DeZr7p4qGRT2paO9fx1P5IqixKuTDMGgnQ77mBtRQpKmbZNobpTEPXGC6 nUVJI44r ffutviz6Fo0gIPNQTaEHjj3lsv+Cu433l+F8YDmvW1jT+ObnTkpr671p2zRipTb2+INzyMY7fwMHJNKBZUtOSMnFnRU8pMnLoF00stDZkS7x4thd0N9KzrEDNBur9sfl0TfSIultskO64ue0lGqfg/7khamh/R8/nH2r4JY1SYcMz5ju5idgt/e7kyc2zDIAuTSCma6Bhu9cJuGz/NLL11HGoaq4ZRpTaaLj0thmBxb9K9KtaUIBOorKMnw== 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 2023/2/22 03:58, Matthew Wilcox wrote: > On Wed, Feb 22, 2023 at 02:08:28AM +0800, Gao Xiang wrote: >> On 2023/1/27 00:40, Matthew Wilcox wrote: >>> I'd like to do another session on how the struct page dismemberment >>> is going and what remains to be done. Given how widely struct page is >>> used, I think there will be interest from more than just MM, so I'd >>> suggest a plenary session. >> >> I'm interested in this topic too, also I'd like to get some idea of the >> future of the page dismemberment timeline so that I can have time to keep >> the pace with it since some embedded use cases like Android are >> memory-sensitive all the time. > > As you all know, I'm absolutely amazing at project management & planning > and can tell you to the day when a feature will be ready ;-) yeah, but this core stuff actually impacts various subsystems, it would be better to get some in advance otherwise I'm not sure if I could have extra slots to handle these. > > My goal for 2023 is to get to a point where we (a) have struct page > reduced to: > > struct page { > unsigned long flags; > struct list_head lru; > struct address_space *mapping; > pgoff_t index; > unsigned long private; > atomic_t _mapcount; > atomic_t _refcount; > unsigned long memcg_data; > #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS > int _last_cpupid; > #endif > }; > > and (b) can build an allnoconfig kernel with: > > struct page { > unsigned long flags; > unsigned long padding[5]; > atomic_t _mapcount; > atomic_t _refcount; > unsigned long padding2; > #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS > int _last_cpupid; > #endif > }; Okay, with the plan above, how to make it work with memdesc in the long term? Also in the future at least I'd like to know if it's possible / how to get folio itself from page and how to know if some folio is actually truncated or connected to some (or more) inodes. Anyway, all of the above are interesting to me, and that could avoid some extra useless folio adoption in the opposite direction. Also I could have more rough thoughts how to get page cache sharing work. I could imagine many of them may be still in the preliminary form for now, but some detailed plans would be much helpful. > >> Minor, it seems some apis still use ->lru field to chain bulk pages, >> perhaps it needs some changes as well: >> https://lore.kernel.org/r/20221222124412.rpnl2vojnx7izoow@techsingularity.net >> https://lore.kernel.org/r/20230214190221.1156876-2-shy828301@gmail.com > > Yang Shi covered the actual (non-)use of the list version of the bulk > allocator already, but perhaps more importantly, each page allocated > by the bulk allocator is actually a separately tracked allocation. > So the obvious translation of the bulk allocator from pages to folios > is that it allocates N order-0 folios. > > That may not be the best approach for all the users of the bulk allocator, > so we may end up doing something different. At any rate, use of page->lru > isn't the problem here (yes, it's something that would need to change, > but it's not a big conceptual problem). Yes, I just would like to confirm how to use such apis in the long term. Currently it's no rush for me but I tend to avoid using them in a vague direction. Thanks, Gao Xiang