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 F2975CFB424 for ; Sun, 6 Oct 2024 16:08:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C377F6B018B; Sun, 6 Oct 2024 12:08:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE71C6B018C; Sun, 6 Oct 2024 12:08:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB0416B018E; Sun, 6 Oct 2024 12:08:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8CAC86B018B for ; Sun, 6 Oct 2024 12:08:11 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 19A64A0F7B for ; Sun, 6 Oct 2024 16:08:11 +0000 (UTC) X-FDA: 82643659182.30.AC0865E Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf25.hostedemail.com (Postfix) with ESMTP id 3CB1CA0019 for ; Sun, 6 Oct 2024 16:08:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=f7Uwq7cA; spf=pass (imf25.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=alexander.duyck@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=1728230821; 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=jsNcMiZIDNLMekYvfzBCcKUfltxAAz74Dl2YC6o5gfY=; b=yCWfYFSXthtAJXzeyf8h13oCvgmPv+TFYLS03Xrl5hb6oRSxEVsdkAtprsPX2gBrei4dGK 6AcU9zKkimA8P3R6cRFPAk/kX36PTTbQP5ld9Aiaxr0vKqvWub63GmmUWhmwPfkrrZ3w6j 1HKCiSixP1hUwokAkPShT1FVeVGPKXY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=f7Uwq7cA; spf=pass (imf25.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728230821; a=rsa-sha256; cv=none; b=qhLmHoXRHSXrALit4fZBW5IIREkbBOMQMWtpwQV0Lwy/bN30QfPU71Djty4rfhtfyiw44y a1zyATPoF5rvlYMNDxuVJB8b/rK02sImgK0NpjmqclsnXgGw4BoqoGyHSgvKIpjkfYsqsj QNCxdmkE2JX4TfmOTIzY3IrhOd0LoOI= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-42cbbb1727eso35870775e9.2 for ; Sun, 06 Oct 2024 09:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728230886; x=1728835686; 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=jsNcMiZIDNLMekYvfzBCcKUfltxAAz74Dl2YC6o5gfY=; b=f7Uwq7cAjyecGvtENjybdIKFym+xyvulFTRcq8UYoXp4n3CBe/yixSoHGCiljqMnqe J34jFgqFjXdvy16FBqPHIxQ6s8A5xmJ/sAEF2RVrngNfNbTpnLEH/mfdp0b1G4oflR9x VpI/O665S4xFv1BjuAdc4vCYtntEdDuua0x7oDDlwb/CyYyAlQecE59Qpvno1wq6aq7c EYfGX1m7uxDGvrC9WMVYB9euekp06TYEhZw7wbhfMCNwyLM2ltdHv/nNxtBZMiuw3KQQ Gfgk7qVBFNe5sglwTb1jrMtvAaQBQV14MHOx71uUrgLpgdCD7qKrbBN8UwKX5ez++h/p MFjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728230886; x=1728835686; 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=jsNcMiZIDNLMekYvfzBCcKUfltxAAz74Dl2YC6o5gfY=; b=Pd3MB0h6qdw2rLYhQDvlbIo1CB+/USbBDn8/tMBqmHucg+70bUj1mkNL4b4SXlhOc8 FxLpGA8gPCHT1VT1E7DgOvrsz3SVCeb5UfwIjZ3AwEoU5yepAyw9dhroeoT4jzj8o3ZN Is41wJ7fjPw3yE6FwQU0+IsD7EKyjO0N8DN/1l5o6ANrP7JFF/92FL3vjUJAMpwxEZtt G4UXYgM+ENqL+sqa/S9Hj2fs2BlKiT9kWTKwS+n/RtscubdWfmpBRowDDrPE65mY8Rrd /AuLIFQVjyKZf3yGaPb/TaOesd8VisqvtqVx2TskIscJs/DCv5ZaO2n8vYpQ/sS9ZnRI lB8g== X-Forwarded-Encrypted: i=1; AJvYcCVABgY+zRWTu9bgc7Df4R4jhYa+kCuKQaer0F2rejvL2gDhgFJnJYsT/cjPpZgLoXvh1r0x+Yhjjw==@kvack.org X-Gm-Message-State: AOJu0YxUbv3QrVJpdCmUTgFKfN3n43d8ml4OOj7n4pF98ln6WOIXNhOQ hFQ4ILar8H0j18GvFrV7cBdVrt/vXTbc+UX33WTDYmKKdU/rye7VHPFIanlawOepQCm/kPeIKqC 7PCrW12VHm70SAp3/xi7IcZwWa+Q= X-Google-Smtp-Source: AGHT+IGOQ41gh4KuGUucHi4/IGlmrEKzSxSXLKsTklVro8WF8T4vcbtIwVd0LSIMqfiDV2eDxJ2FnO9Uy0WyBPbNGn0= X-Received: by 2002:a05:600c:35c9:b0:42c:bb41:a079 with SMTP id 5b1f17b1804b1-42f85a70035mr75631645e9.1.1728230886201; Sun, 06 Oct 2024 09:08:06 -0700 (PDT) MIME-Version: 1.0 References: <20241001075858.48936-1-linyunsheng@huawei.com> <20241001075858.48936-7-linyunsheng@huawei.com> In-Reply-To: From: Alexander Duyck Date: Sun, 6 Oct 2024 09:07:29 -0700 Message-ID: Subject: Re: [PATCH net-next v19 06/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, Yunsheng Lin , Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 3CB1CA0019 X-Stat-Signature: mbumst9tw43k7gpuwfigjaax6873s139 X-HE-Tag: 1728230887-342877 X-HE-Meta: U2FsdGVkX18NIuTduowuEYArcXuduAoq1GPMBjztihPq8JQ2qPWiYZOUEzUPW2K2s0beSnIB5ll/9VWwkMFJjTlnDy+2aHUDCvIX68/FV8x9Q29tN68wyC+r1TnNl3gjHm++ge7ptZZrxw2d/zVg+8jXdAxTpolDVg4NYJ2GRcQqAUWmyLs11JQZscjh6f++j1qTk7klLTtofKNkVSP5rDYEwhgU7ZEohkbOu1xLzngXEOPBD+T+I7m9b7iDhuyn98dPBADYFVP/pVEWmNbD23LdkppYg+DSvZaL+1eKISBFOmQaXDq5h2n/OEL/YtMtkdNDjcl+IRbcfVFLMnBtuHy6zm0uH8W/8BeM65/5hcdUNWj/+7AKE/6iof7rR1wgAZBW9Fq1dkkOSYlCGohR7BGUWXbzQnTJsKiABQ1zMxrsIVsOKSNJxIjySVZoQ61MuZ5L3uIZwlzUSxsNf6HJ8hTK56P5CdaK90wDDNw2xZ1RCwzP1aKa/Yb6MYHQsvc3O7s0VZsjBjrhii9qvU/wOz2nsn1qa63PjoFnes1xVv3qNci0EyZBSoLCwJo/LZN2BWMILEFLjPp1PtoKNw9jnrNCzp8yUNuQP8t8XRkZjPoSdHr47bToa76sR1xPkT7TeU5bIB/RWB32Ljw64YsLkVzp/BezzeltmBE/nP7q2CvMmOuegZapx6sRkvZn4ybBCy+LxiRzlypn/YANDHl4TKklpryMgkD+Y36DkTcJ1FSXIcYzWj6IWkPa49kejSYN+hpF4SdjqJ+MIO/4t+SU4+yleb0lAE/yX/gr8T5qgwZtMc0uD0eGMWkiCWELSOfjpqyLGPQIGsUt1iUIkdpyGC9iaSKWEaM8yEwFBHV6I5nN8fdtBuT/N79mM+gBMEzYMPk74anHK9bFGvHG1OCXXenH85ajr4NJ5VAUhY0YeumLHpsUp3SuSn7xzlLAmXMmX+2UDe8OYsFfVaGRWAI PyHJt08Y GEbVs+hJn68vYZ35Rdd8HlcBomiSxR//pzPCC8teM8Vp2bfvl+2HnAMcJWE+fIpKSBcBJSCZw5jYuA+sHtVWVgxBNPB7jY/qpAp3v84/jg9fUzDdZLmKnQF8seCxpldzXY1cpx50f6vL5mFwzEFPuqX0V69MnQJUlaUwS/LktEVK+EKNW+/Yfche940bX5Y6xjxvTKEf/xvoc7e6C5tp1HqRlNfHZh/UBbg8Cmvv+L5bE7dJN896OjH5QCeK7BXWjZyLydxpIG6W1Mc8yn7Z+opwXHzwyYZAZ9Gi3R9EU/cYAT+PeLN+Bwag3AMeK6PsDJGMiC6oUVMPesdMX106cuW6Xb8td10u1qLQUO9HnO9mcUVAMOt2aZs5W+7JVkZPxPx7IH/4Pg/YYbG88y2myM+P0M8eRmKs4B2ME+w78V2yolMrFLz7u3d6HVNokxGevO5VZ 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 Sat, Oct 5, 2024 at 6:06=E2=80=AFAM Yunsheng Lin wrote: > > On 10/4/2024 6:40 AM, Alexander Duyck wrote: > > On Tue, Oct 1, 2024 at 12:59=E2=80=AFAM 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 | 19 +++++---- > >> include/linux/page_frag_cache.h | 26 +++++++++++- > >> mm/page_frag_cache.c | 75 +++++++++++++++++++++++--------= -- > >> 3 files changed, 88 insertions(+), 32 deletions(-) > >> > >> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_ta= sk.h > >> index 0ac6daebdd5c..a82aa80c0ba4 100644 > >> --- a/include/linux/mm_types_task.h > >> +++ b/include/linux/mm_types_task.h > >> @@ -47,18 +47,21 @@ struct page_frag { > >> #define PAGE_FRAG_CACHE_MAX_SIZE __ALIGN_MASK(32768, ~PAGE_MAS= K) > >> #define PAGE_FRAG_CACHE_MAX_ORDER get_order(PAGE_FRAG_CACHE_MAX= _SIZE) > >> struct page_frag_cache { > >> - void *va; > >> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > >> + /* encoded_page consists of the virtual address, pfmemalloc bi= t and > >> + * order of a page. > >> + */ > >> + unsigned long encoded_page; > >> + > >> + /* we maintain a pagecount bias, so that we dont dirty cache l= ine > >> + * containing page->_refcount every time we allocate a fragmen= t. > >> + */ > >> +#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) && (BITS_PER_LONG <=3D 32) > >> __u16 offset; > >> - __u16 size; > >> + __u16 pagecnt_bias; > >> #else > >> __u32 offset; > >> + __u32 pagecnt_bias; > >> #endif > >> - /* we maintain a pagecount bias, so that we dont dirty cache l= ine > >> - * containing page->_refcount every time we allocate a fragmen= t. > >> - */ > >> - unsigned int pagecnt_bias; > >> - bool pfmemalloc; > >> }; > >> > >> /* Track pages that require TLB flushes */ > >> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag= _cache.h > >> index 0a52f7a179c8..75aaad6eaea2 100644 > >> --- a/include/linux/page_frag_cache.h > >> +++ b/include/linux/page_frag_cache.h > >> @@ -3,18 +3,40 @@ > >> #ifndef _LINUX_PAGE_FRAG_CACHE_H > >> #define _LINUX_PAGE_FRAG_CACHE_H > >> > >> +#include > >> #include > >> #include > >> #include > >> > >> +#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > >> +/* Use a full byte here to enable assembler optimization as the shift > >> + * operation is usually expecting a byte. > >> + */ > >> +#define PAGE_FRAG_CACHE_ORDER_MASK GENMASK(7, 0) > >> +#define PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT 8 > >> +#define PAGE_FRAG_CACHE_PFMEMALLOC_BIT BIT(PAGE_FRAG_CACHE_PF= MEMALLOC_SHIFT) > >> +#else > >> +/* Compiler should be able to figure out we don't read things as any = value > >> + * ANDed with 0 is 0. > >> + */ > >> +#define PAGE_FRAG_CACHE_ORDER_MASK 0 > >> +#define PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT 0 > >> +#define PAGE_FRAG_CACHE_PFMEMALLOC_BIT BIT(PAGE_FRAG_CACHE_PF= MEMALLOC_SHIFT) > >> +#endif > >> + > > > > Minor nit on this. You probably only need to have > > PAGE_FRAG_CACHE_ORDER_SHIFT defined in the ifdef. The PFMEMALLOC bit > > I guess you meant PAGE_FRAG_CACHE_ORDER_MASK here instead of > PAGE_FRAG_CACHE_ORDER_SHIFT, as the ORDER_SHIFT is always > zero? Yes. > > code is the same in both so you could pull it out. > > > > Also depending on how you defined it you could just define the > > PFMEMALLOC_BIT as the ORDER_MASK + 1. > > But the PFMEMALLOC_SHIFT still need to be defined as it is used in > page_frag_encode_page(), right? I am not sure if I understand what is > the point of defining the PFMEMALLOC_BIT as the ORDER_MASK + 1 instead > of defining the PFMEMALLOC_BIT as BIT(PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT) > here. Actually the shift probably isn't needed. Since it is a single bit value you could just use a multiply by the bit and it would accomplish the same thing as the shift and would likely be converted to the same assembler code.