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 35A01C6FA8E for ; Thu, 2 Mar 2023 04:16:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6B6B6B0078; Wed, 1 Mar 2023 23:16:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1B9D6B007B; Wed, 1 Mar 2023 23:16:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E3936B007D; Wed, 1 Mar 2023 23:16:46 -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 7CAB26B0078 for ; Wed, 1 Mar 2023 23:16:46 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E3B6C1C696C for ; Thu, 2 Mar 2023 04:16:45 +0000 (UTC) X-FDA: 80522647170.20.FAF3C7D Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf25.hostedemail.com (Postfix) with ESMTP id 21223A000A for ; Thu, 2 Mar 2023 04:16:42 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=A1EaYf8t; spf=pass (imf25.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677730603; 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:dkim-signature; bh=OiLX93qNxOIggMQE39gtCyYpTO910rpc2HqmiyP4Wqs=; b=P1BAO86IQqVQuKZ1C/IZT6dC0XR82xO2vRzBG9BrCvHgCChE0JOjRKGfvCYVVomM6pQAG8 1sChYaeMlnuLwVNe6rMP0GHxtdEt3qZK/kt8bX+nSbzv7J0cBkMpK4mbYshE2U4VtjtCRy 3ug0FnnKKwwPBmOxX0L4VE3SAJsgAlE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=A1EaYf8t; spf=pass (imf25.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677730603; a=rsa-sha256; cv=none; b=pIHeDw4LoD0W1jepd1aAJWflM/vGsTUZItyl/Rf2iQE81zLg1xEAYPL/M0lV+OhRoFZ56q aFxR9Z7ib9PobdNpfmt6VrqA8sCZBw0rjqWUUaRyeU+U91Q5+92VFF+dCP4nvOCUcYoJLr WDLPiNGEO1m0gom4gM1rdNetj9nt0iA= Received: by mail-qt1-f181.google.com with SMTP id ay9so16827842qtb.9 for ; Wed, 01 Mar 2023 20:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OiLX93qNxOIggMQE39gtCyYpTO910rpc2HqmiyP4Wqs=; b=A1EaYf8tKwM+OSZSx4sx0qUaPdLBesg9gHN2HlrQvObNa2lqTRK6IIiYpalGERQjcF pn+3xJBA/2791KiNqkOv//qXihovDpzswgjkqop1IXsV/L8NKh0Reo/ds5+FfnISkwnR I4WYiYH26wHIo2lOKIbarUgozHVzZhjq93i0zsrTBDllz8HnRhjt1fP7c+82n2uMukdc FrBA3ORoe7jdcFdPw9qrbyGt3C0CW2OrZV5E0sHojytvWDuV8PlYeOB/d3LJNDdjuJSG uvSrX/ZjBU8NVnQtHqnVeKjdMBgeElsggH2A6HgKfI3fDqki+55VcLxx2U4VMZJDfP6k wNBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=OiLX93qNxOIggMQE39gtCyYpTO910rpc2HqmiyP4Wqs=; b=5k7AVjA5GG/PC8wx5Cj0AVvcR+KpxwCkKQZkVusATLP62btFkIhS5KriK2+sqb4fCJ xq1IS2y4cE0Esg66wR7rGYf9M3xgE6bc1M5IU/6ipww4LVkYanD8HkgHMB9hqFE3rwwA GuSzrK0WLLkn15hfYH22/7i79jsBqvYrKWKQAjj9YHk8f/aQ4xB9I1ohMmzUsk9QtWTN xpqNd12D5zxH5NU7L+uYZgeub+2eA2gb6G6asKK1afxu3kiXVfb1QXBOFg+jsjLoDejJ ZbwMW2HkmLTOilX7nyTmQOFxkjcLNUDx/s90NVxb8UtKEIPEJknpd01GxOyHxXRTh6DE BzFA== X-Gm-Message-State: AO0yUKXi9F1ZGDNdfATIin19muh/NFnmyqDGBFO7hiHRJYsFJ0NTVUbx Jgp0sZYMnfOOjSYliICCuLCXPMJt/tC9r7M7OYAnN/gLVSSQ4w== X-Google-Smtp-Source: AK7set/1Qo/2N3JCxnEKF/vVdWvMT8KXKuR0NcpsojQRCVOxjmuWm2l5Wboe2MANA6zXLOiyu1AmcY+R5Hl0TYWvINA= X-Received: by 2002:ac8:444a:0:b0:3bf:b844:ffc7 with SMTP id m10-20020ac8444a000000b003bfb844ffc7mr2387535qtn.12.1677730602197; Wed, 01 Mar 2023 20:16:42 -0800 (PST) MIME-Version: 1.0 References: <8448beac-a119-330d-a2af-fc3531bdb930@linux.alibaba.com> In-Reply-To: From: Pasha Tatashin Date: Wed, 1 Mar 2023 23:16:06 -0500 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] State Of The Page To: Matthew Wilcox Cc: Gao Xiang , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 21223A000A X-Stat-Signature: 58pt7dx71ez7trwzw6dnb5e8gi43mqp4 X-Rspam-User: X-HE-Tag: 1677730602-595213 X-HE-Meta: U2FsdGVkX1862sZRr1sNy+fmKVLyKUXqrPkoBD+1v5NxjrJw2WO5Ki2JC4HIa9pvOVVaY5coDBZXpl9q7KCoNQo3c1eSGzN3yA57Pc4jtQLEoX3tiAs5HSs10xGp3YUIlC1MqkKY4Q17zBNhWBc71ORbH3KrEqUlAMueAEU/XD+VC64ymXC6voNO/syuxq/V3pV7nA4wlQIaSj5RRdD262Zl+BkOZ2vtVuPTzeNY7jAYsyNAtLUym74VbcQeqLNXIC/NtiX4kOFQp6QwJq2QBB+OkSpRQ/k/I08quejApT1UyW4kg8eAR4AP3VFiXuGSJEOst+qM8nmVNxfHvMnccMxgeHDI53NDJelZpJdHxMkMhvu6Q7XemDHuAKECB1Px8CQUReTo6atGIAp7dFvPh6tJAH7/++HFkrdBry5wr7ChzaLHLLOX2qk0bD2FIna0pwpUULzibR+AxzESwRV8OFSXPCyhdj3fhYFF/DdNBdegHahQP/G36M7iXk0cKJ6WZaLdGuVokvGPqvNK2M0/NIQvrPf8tLBUmWSJ9GseeGQ72oeFO0uoIGXJtFPyHDSuF9T7CT1sXVoXBdgwd7skOy6r6SUveFBK6Mmgm1QSp/pAKREFhMJaQCLNR1G2hBRey7r1Cm6odC23BmnM40fV3Q3YbRs0wVjD41KcvQ07gqhCdh/KhOXGWaVdkPk00QDEUxVhXcyouC4VpCsfjWqyOcqyjJZT6GzjxRh1PHS7gBIrv8CMYEVwHzNPKAYk4+WBY/FOmTG0qbmGiuFC4M5bdPFTZj1OdBIFZucGuTXlEOCgM0EVNB7vXj+8T7FOM/JKz9eJ2F8g90qXLqd3UkkTZumjldEJs3N8puaxnogrCQ/M/nDnoZk8bz220cwSwfjnNv9i031NLperQ63NQztd9qQXs+RgXD+6P7XNagmac7euDmaxWusVtsIhxTekNcsmEXq5O6PR6UIdCs/0cwr qC/Bqbsg X7cTyZ6SWl1HOqivEHDYkm2zGNsMJT+8WbAMGBczwp274bh9s/rbnvBT1Bswt3A3jeZreWDktt5B4JlrPotsNR8yhmSYexhw8OoHjeDIHr4qKXvoivgmqDkgdp8KK4+FLmaitVoP5oKpGOgF0rh+7ulKHB/f6awXQ2uQ3L+Qoq2EnRz8k+kP8oQqgSkSHfms40Eb3uQMJyRV8C9k8iRTcd4q9wHWh7EXbE/WN/xyxZr0Bgc/uAXSV6UKgioo1Gl8Diq6HLdX/BwOSjyTm5Vhgp3Dm/Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000147, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 1, 2023 at 11:03=E2=80=AFPM Matthew Wilcox wrote: > > On Wed, Mar 01, 2023 at 10:50:24PM -0500, Pasha Tatashin wrote: > > On Tue, Feb 21, 2023 at 2:58=E2=80=AFPM Matthew Wilcox wrote: > > > 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 > > > }; > > > > This looks clean, but it is still 64-bytes. I wonder if we could > > potentially reduce it down to 56 bytes by removing memcg_data. > > We need struct page to be 16-byte aligned to make slab work. We also nee= d > it to divide PAGE_SIZE evenly to make CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMA= P Hm, can you please elaborate on both of these cases, how do both of these cases work today with _last_cpuid configs or some other configs that increase "struct page" above 64-bytes? > work. I don't think it's worth nibbling around the edges like this > anyway; convert everything from page to folio and then we can do the > big bang conversion where struct page shrinks from 64 bytes to 8. I agree with general idea that converting to folio and shrinking "struct page" to 8 bytes can be a big memory consumption win, but even then we do not want to encourage the memdesc users to use larger than needed types. If "flags" and "memcgs" are going to be part of almost every single memdesc type it would be nice to reduce them from 16-bytes to 8-bytes. Pasha