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 1425EC52D6F for ; Mon, 19 Aug 2024 16:00:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91D586B0085; Mon, 19 Aug 2024 12:00:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CC8C6B008A; Mon, 19 Aug 2024 12:00:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 793E46B008C; Mon, 19 Aug 2024 12:00:45 -0400 (EDT) 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 552996B0085 for ; Mon, 19 Aug 2024 12:00:45 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D798814140C for ; Mon, 19 Aug 2024 16:00:44 +0000 (UTC) X-FDA: 82469458008.06.D2D278E Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf15.hostedemail.com (Postfix) with ESMTP id 5FA40A002B for ; Mon, 19 Aug 2024 16:00:41 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kWOqECHR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724083154; 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=eWbJ0BhqL6s2vTUYqgwljUkHYPKs32/xl7KupWHrSQw=; b=uuxhrCvjOIX6VnD169Q+rgxRrn88zNSiiwFsNykMpOAf6A52/MMRvTTXyEjOtd/1ia7Zhs nepu7lIRRilUnn8nbuRoXBt73mw7Wcg1P/b9ohLUQXMqKYhvtqhW70Yb66NB1/0GOwZzCI ixxcRWMl+eHMo5F0AJFk5opeFUknMo8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724083154; a=rsa-sha256; cv=none; b=WYukJ05XujKF5R5STyA+NUv7ARYXfWPFmv2votNb0M/oEBL7PmV8B6tjH37vEwGtQh40OM Nf649/KXjR12xhTfqGA1YVb4owy1QE3NGOWv/av4xHfU3xDCFX6Zldy6Rhprf1dHtBCE1f 3a9B30iMd6KHOQfd105fz4NH8Db15m4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kWOqECHR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4281faefea9so35252235e9.2 for ; Mon, 19 Aug 2024 09:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724083240; x=1724688040; darn=kvack.org; 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=eWbJ0BhqL6s2vTUYqgwljUkHYPKs32/xl7KupWHrSQw=; b=kWOqECHRdVC5EmHBf3H77CcrYGwLEp3MhPH9jcy0gY00EQDM2+gpmzrfuD0EQ2FTVh UkO2yEBS/ileRYraqMYWAdHGeNsaL6XcaPwg1lQfvN6Pc9x8kg3ruFSvtSjTAkOEwm7m MdjMu8ySyVvG/E2nsNGWrJG0fTl/JUrBGqUnnmvlwBZtID0XRdNILRxib1gjOY0pWeib 3Ax6IhCxHlkix3xsLZELrYX+OLKowbJwQMFILXJ7T7Fw913G9w4kfUCCX8iQFxnLrkGi InM49OD+A3Uy6jnG9efAAGw+/+7L7xB2xHHD79xmDZMApbHWlYswVRsivB+UTbRXOkzA apJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724083240; x=1724688040; 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=eWbJ0BhqL6s2vTUYqgwljUkHYPKs32/xl7KupWHrSQw=; b=JOedPQnJiearMtIYzS3tr//DG4PLHCxMcJwq0KnvDFPHu/9Er4pZeMgZEksVMTToqg 2PkGu7y8cPTG5DfIRJ0Kyd8QAAxe8Otkzs8/RJ8D7+9govBK2Hwzo+o5QoMaP9uRADMC nGWV9rBY7VLwX3RvsTjDXmh/YHvdt8jsBHKcKWW5zeb0dKLA6EMU/uoxGJFiqDM/+zT4 bRFtWfaI7avsRc44yp/rvrhgQQYljCYgyCsou5vR+sbwr/xOEjqdJGiuq2NuYeTmJk0b Yx0X0LO/ImhpKrn6/p2vhFUhbJmk4ie5LHsHBn8c6wyzgZIRBj3lwxA2an/NifM1konz OjEg== X-Forwarded-Encrypted: i=1; AJvYcCXrn6Z99uCrJGL43Y4CAEgtHRtLiSQLdLoPuvDZSlfsjApBL4fz1lgE09EduGYHT0R7aOd59ZrisA==@kvack.org X-Gm-Message-State: AOJu0YyWlUsIMA1MLx42zvD/PsImNPl9VUVMuK9x9Sbb1rw2TmTs3kv0 c3dGKm0Q6VWT471sDW+1/NFS7JVHd3NqMiGFyONKzbFNK4PLseAA+Z2dSt+NFE+MPXz0AFirv4x zMOhQu8oveCZRevdPeRUUbKBY0RoIZ06Y X-Google-Smtp-Source: AGHT+IFv0JarxFL93l4RwfEzjHDNqs6h6zrrWLAttKmO8FvHt3HiRgMIKiWxxsosOtDijZxju7uE95jYZNxAsaInboA= X-Received: by 2002:a05:600c:1d95:b0:426:6eb9:db07 with SMTP id 5b1f17b1804b1-429ed789168mr71821225e9.13.1724083239371; Mon, 19 Aug 2024 09:00:39 -0700 (PDT) MIME-Version: 1.0 References: <20240808123714.462740-1-linyunsheng@huawei.com> <20240808123714.462740-8-linyunsheng@huawei.com> <0002cde37fcead62813006ab9516c5b2fdbf113a.camel@gmail.com> <1a6aab37-2783-45a2-8edd-0990b211ac2d@huawei.com> In-Reply-To: <1a6aab37-2783-45a2-8edd-0990b211ac2d@huawei.com> From: Alexander Duyck Date: Mon, 19 Aug 2024 09:00:02 -0700 Message-ID: Subject: Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc' To: Yunsheng Lin Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5FA40A002B X-Stat-Signature: xzg996wrjmjagdr9wu5g9ot1n39mz4w9 X-Rspam-User: X-HE-Tag: 1724083241-690195 X-HE-Meta: U2FsdGVkX1/Z8JYNYE7R0waiPHwO05GgV7iIqQPLMhK9GJfQ1T5DHL2NxpVNVTkx5MDbNw1/XJYILgsUUIpK4IEjCGGu/PaKbcnnrs7NDLKJBN3NtmcVwY5P69ld7XHzBgj6AYPc2ahIMP0yAN0WZF6GQPrssIvYTJjzUkKkufRJADqudBYudSw8hw2ie2PUBw2ypWgwQ81chbWa9MmEyQJuVJZpFDjqlIsZgQOBC0Vc6AFw8ZlMTdW/V9krYzZaMC+B8jIc/ROUvzvVZORN3GHV1FyfhD3L2x2m1qcMCxsFcPivqwSjmm1m1WAG3yu/jzhMLEHAEn8JJjlHP4uHMniwcZD33lWMeFOB9CiUUIYpygzETXbxeEZJLoodVcXGFtjsQ8bwrWdXbpfyYQR/uxu612AbPn+ABVcMtVd+Uk1nq2B+wHgJwVf+tMkMMcyEOfT9u5gubksEfOHo+fdvWSq0srOShMkIrS9sBzJ/8ciO4FeUOdcG0JRVdpzeNYGjuTjbTE5MWItwUpslW1K+NjzusDCo9RgWxJtN1eBoVXF3JlnV9TZL68xdooLjjxM8F7BQWtXBnvmbLUSCnXRMR6Aj07tbEdM79kqcyoLyxSLid5Z+z+sJax0ezscSCn8Qv7r/SaJ3xT2wNCCh0U1w0YCUUfsZQwtCKXHkLGhXzm7j2MA4F69LWrl9sFs84k3M1cD23kLmh2jQnWfViQJgSuKGXKXXbSWi9fMFSfRQstiltKfaF9bhy8zDvihuV0YeJzZU2MyiME6g0ufTvKZ8yhIIWgJtGLYF7uBxriBDVGXqHL0uu4p14F+M/hT0KxsdpSyHUTbqJk7voBWLcdcaTxNKs6bJQjYS5jW9ZqKVMO7jGF1VCl1CiSTxrcXe8R/R0IgSBKV7GkHI2VPFXtindPxADlyvXmuacdsJPAVk4MOWiLIS8fW4Ijt9gsu8vzTTSiQ/kXNuUDMoh32h9AL aoBK0ehg YxYKCO1/qLvFD4L73JCeebvgfXm+BvMRoBrEnPeQXRsnnWzoNAA6Wh4XHUaqr0G8dPRlleGB4HLEncu8D4eDmVAsjli/9NpYF9K39ancJjYThLqa0xgc5RYyauj5ZeJH5qkmzNbi+TriqgcBNNS2g8UCXwnG73tnSj6hcQ/VBJ0mWXuUIxKbw+yckaTw/kK3tsTHuoGyneXVsXzr9Z5IDHAZ1gjpBSuyHt4Ty1Xv/EL5dbi3cELoWPaMETejriHkypWyDo51YAhngM3rZVqi42ckCrv88vEsWQs/a7VEcZRI6sMPkZjGZMbnas/N4m7eRWN4RONXHxqYFh97i2Baba2hAdx6dD8rWMjLRI+OJYuufpBgYPI9GbwmInVErnMB8Q4S8osCvyQehVHnmoOrnARDZcabSt1sxp30n 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: List-Subscribe: List-Unsubscribe: On Fri, Aug 16, 2024 at 4:56=E2=80=AFAM Yunsheng Lin wrote: > > On 2024/8/15 23:03, Alexander Duyck wrote: > > On Wed, Aug 14, 2024 at 8:10=E2=80=AFPM Yunsheng Lin wrote: > >> > >> On 2024/8/15 0:13, Alexander H Duyck wrote: > >>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote: > >>>> Currently there is one 'struct page_frag' for every 'struct > >>>> sock' and 'struct task_struct', we are about to replace the > >>>> 'struct page_frag' with 'struct page_frag_cache' for them. > >>>> Before begin the replacing, we need to ensure the size of > >>>> 'struct page_frag_cache' is not bigger than the size of > >>>> 'struct page_frag', as there may be tens of thousands of > >>>> 'struct sock' and 'struct task_struct' instances in the > >>>> system. > >>>> > >>>> By or'ing the page order & pfmemalloc with lower bits of > >>>> 'va' instead of using 'u16' or 'u32' for page size and 'u8' > >>>> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste. > >>>> And page address & pfmemalloc & order is unchanged for the > >>>> same page in the same 'page_frag_cache' instance, it makes > >>>> sense to fit them together. > >>>> > >>>> After this patch, the size of 'struct page_frag_cache' should be > >>>> the same as the size of 'struct page_frag'. > >>>> > >>>> CC: Alexander Duyck > >>>> Signed-off-by: Yunsheng Lin > >>>> --- > >>>> include/linux/mm_types_task.h | 16 +++++----- > >>>> include/linux/page_frag_cache.h | 52 ++++++++++++++++++++++++++++++= +-- > >>>> mm/page_frag_cache.c | 49 +++++++++++++++++-------------= - > >>>> 3 files changed, 85 insertions(+), 32 deletions(-) > >>>> > >>>> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_= task.h > >>>> index b1c54b2b9308..f2610112a642 100644 > >>>> --- a/include/linux/mm_types_task.h > >>>> +++ b/include/linux/mm_types_task.h > >>>> @@ -50,18 +50,18 @@ struct page_frag { > >>>> #define PAGE_FRAG_CACHE_MAX_SIZE __ALIGN_MASK(32768, ~PAGE_MASK) > >>>> #define PAGE_FRAG_CACHE_MAX_ORDER get_order(PAGE_FRAG_CACHE_MAX_S= IZE) > >>>> struct page_frag_cache { > >>>> - void *va; > >>>> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > >>>> + /* encoded_va consists of the virtual address, pfmemalloc bit a= nd order > >>>> + * of a page. > >>>> + */ > >>>> + unsigned long encoded_va; > >>>> + > >>> > >>> Rather than calling this an "encoded_va" we might want to call this a= n > >>> "encoded_page" as that would be closer to what we are actually workin= g > >>> with. We are just using the virtual address as the page pointer inste= ad > >>> of the page struct itself since we need quicker access to the virtual > >>> address than we do the page struct. > >> > >> Calling it "encoded_page" seems confusing enough when calling virt_to_= page() > >> with "encoded_page" when virt_to_page() is expecting a 'va', no? > > > > It makes about as much sense as calling it an "encoded_va". What you > > have is essentially a packed page struct that contains the virtual > > address, pfmemalloc flag, and order. So if you want you could call it > > "packed_page" too I suppose. Basically this isn't a valid virtual > > address it is a page pointer with some extra metadata packed in. > > I think we are all argeed that is not a valid virtual address by adding > the 'encoded_' part. > I am not really sure if "encoded_page" or "packed_page" is better than > 'encoded_va' here, as there is no 'page pointer' that is implied by > "encoded_page" or "packed_page" here. For 'encoded_va', at least there > is 'virtual address' that is implied by 'encoded_va', and that 'virtual > address' just happen to be page pointer. Basically we are using the page's virtual address to encode the page into the struct. If you look, "virtual" is a pointer stored in the page to provide the virtual address on some architectures. It also happens that we have virt_to_page which provides an easy way to get back and forth between the values. > Yes, you may say the 'pfmemalloc flag and order' part is about page, not > about 'va', I guess there is trade-off we need to make here if there is > not a perfect name for it and 'va' does occupy most bits of 'encoded_va'. The naming isn't really a show stopper one way or another. It was more the fact that you had several functions accessing it that were using the name "encoded_page" as I recall. That is why I thought it might make sense to rename it to that. Why have functions called "encoded_page_order" work with an "encoded_va" versus an "encoded_page". It makes it easier to logically lump them all together.