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 80AF4E77170 for ; Thu, 5 Dec 2024 15:20:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AE0C6B0121; Thu, 5 Dec 2024 10:19:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E19D6B00CB; Thu, 5 Dec 2024 10:19:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 200F86B00CD; Thu, 5 Dec 2024 10:19:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BD4AA6B0363 for ; Sat, 5 Oct 2024 09:06:08 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 31F7F4022B for ; Sat, 5 Oct 2024 13:06:08 +0000 (UTC) X-FDA: 82639571616.18.18A587B Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf11.hostedemail.com (Postfix) with ESMTP id 2A06E40005 for ; Sat, 5 Oct 2024 13:06:06 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DE4YXo5k; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of yunshenglin0825@gmail.com designates 209.85.216.68 as permitted sender) smtp.mailfrom=yunshenglin0825@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728133469; a=rsa-sha256; cv=none; b=fVkABqHeSAoVKzOSmDZG9dchoWMzHiEev1TZTed1KlQa2bndXuBXwOFQbgk70cTGhFQceV +iuvmDHNYmdkqubkO9KJfCBIY77Q1yDP0I+fFceTdIwsImWiXdrLPs7yKQJIP5WD1oEhZ/ rY1Ev0sXlKT0RsYSKwMKOTfFBhDwvFU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DE4YXo5k; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of yunshenglin0825@gmail.com designates 209.85.216.68 as permitted sender) smtp.mailfrom=yunshenglin0825@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728133469; 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=Hg48AfVg4iIkxwZq81/OtuV4OVmfBvrxi0OXE0Y219k=; b=8YsJtR2ld42Y0e7y+CwBSNZu0UZXCX0qhWkx3ac6WHWA+pq7z6q3649UeOLfkx+7rkrbaI Lbfx+iG+uZSxwoXAHZXouUIPa36/v5wKwainE0n51K+ohPH2XPpHmhK7ebOEL5EvcOfyY8 bzLaMuRfuvBZT/d9In7pp3MRX7ZJHcE= Received: by mail-pj1-f68.google.com with SMTP id 98e67ed59e1d1-2e078d28fe9so2153626a91.2 for ; Sat, 05 Oct 2024 06:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728133565; x=1728738365; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Hg48AfVg4iIkxwZq81/OtuV4OVmfBvrxi0OXE0Y219k=; b=DE4YXo5kBReD8AvrFQQhC8wuN1QnzblxdfQX0na+j6dusAmkKX6Q2WjklFXdKvEYCY 0828xgDtv0MF03p7y78+zEDYpcZNCoSefv0GB8dLvLO7Mv6b7LGddNZXr6lfbKnYVGPO cVygtMHTp/cP9n0eNtbgnB4XrODrBmfCPeQhfyayiMZsT+2UVw9uTl2ge22f1zd6C0w1 BjpxRDgn8WFjRldn+Bb+6CilCBRBYUrqg0usf3wf54+bNkeaO0SF0MDLSG9F14ODL+A7 XSyojKzY9IwI0pFZTaSlSO5mgSuXl7HX3YImsqq4G7WvynoykOJT/Q0Oo3vpkZtQJNTt AzIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728133565; x=1728738365; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Hg48AfVg4iIkxwZq81/OtuV4OVmfBvrxi0OXE0Y219k=; b=jIyJIQpXTftGyBoB/VNXQclsDWxqWMfYJYqCB88JKUeiTXHEzfwnZz+dRswIun2B/d nqUZF2xk+a2lJkNu6LdcVtkO35f7DTu7Z54wRZl+YCsKgVYkb51lXaLrso+XyepQwrRv C1WPd6ZPcr7dTiLN7E8G+Wpj8jXCChPwoIUe7HkWOt+SMxFLRa5t/1o0+Vlno6L6+nCK 5VHMydZonHXt0gK8LBI9Yhwc4ExGFwQR2Jl12YMHdZPYkrluiC0JmELevbBP1VpLotJF DLnIhqCDPcYB1gupxZ3f732s2uiXtIg1Y5YMrMY55LbMebj5SiRP7fsueHdbYEjWnkDl X2qA== X-Forwarded-Encrypted: i=1; AJvYcCXaGM2RLDaIF7yYDi253qU/dEuIGgYDio1PPBgymZCN0RDIV1rGC3O0+EMidM+BPj/gdjt+/akL9Q==@kvack.org X-Gm-Message-State: AOJu0Yw+buAVURWpg6XKRYFmJo/F4V6L9edW1IsrEdL31m04id/bg6g/ t0zuXUczp6wqotQ+6TnA52g6rS7fJJWD3N8J1sCbmCmaCyxiBQqW X-Google-Smtp-Source: AGHT+IF3kshIjnF9QwxPbr5fL7fn1RcF2PSt6GXIBxLOyUN0t3o65Fq71G2SDRaKi1Uqhg2xzzsRaw== X-Received: by 2002:a17:90a:658c:b0:2d8:898c:3e9b with SMTP id 98e67ed59e1d1-2e1e631ec64mr7125545a91.25.1728133564672; Sat, 05 Oct 2024 06:06:04 -0700 (PDT) Received: from ?IPV6:2409:8a55:301b:e120:3c3f:d401:ec20:dbc7? ([2409:8a55:301b:e120:3c3f:d401:ec20:dbc7]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e20ae7177esm1790175a91.3.2024.10.05.06.06.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Oct 2024 06:06:04 -0700 (PDT) Message-ID: Date: Sat, 5 Oct 2024 21:05:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v19 06/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc' To: Alexander Duyck 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 References: <20241001075858.48936-1-linyunsheng@huawei.com> <20241001075858.48936-7-linyunsheng@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 2A06E40005 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wygno7g98ykjmsqt5kcz5taiyf96hmg3 X-HE-Tag: 1728133565-418589 X-HE-Meta: U2FsdGVkX1/zt2W0X3fDhGbVv1f9lK5f7kP2OWCQsAzlemrkyCDAMliC6bpnA2UM3hFwwOoh/k/xuEYKm5i7Z3OOxDpONh/PEiaV7oxcJdLYjQvswJJdIXO/Ee0qutyYYc/w8AfyqvpymAEKIVj14bgxN0eROCti1VD/2bnIkj/dXq7kJDBPaEOXSQbOAEh+auFkHlPeOrG7yURRXYbQE/oouckeq96kKOSRIFboMZqKZBInR5ZesktArQPkXGvB2iuhntRVEsr0+3lxQobTFFs2z/z/I0XFBvWojI9bWBjKb3wfCYFYEEItUwdTRC3KhIJXn9k65R/rHiSma3IS3pT6+nw9tcD1Jb+mg2nwhwyRNPWfMgYXBmU1j/vqZr9WMdVTDDQRs4N6CjVC1FSMzq3LSY+NAwMIp/68xolR7nj7TJkHP7spWhC8pctrzSZUYzdDa4tijjEKYk30e2bocv4/SaabF5av4WTA4uM5EpN6l7GB1gdntfc87UAVwVhLRooH0lTZjyvBuOEVP74kA1KODEt/3rJhHe0e5oxK+HHcVAM8dSFyZFenLtGuwgBhm61iqL2LCTsl2xrYsddt8YrDcwbznXj/Wh1GUNdUOosHkviFWgN2l1yN9QHl0zmeAQDJzEw4dO9q9oNO+TKpvO+BwP6evtZBC6Hms9ASNX8qlo+Y31jdgjoII4Pifx8sJAV9WJYjiafKN55ZiN6q+ISK1HgiDCOOhd1R6CRQ8lfufbg96+pChrAk0uHvP0kb7QUBKoiuKGNltPcABRb8CSajkfE16lYmmFO0p9NpDlQoNga0zTjRkgEDw36zNDGlO4Pj0JM8YwtM8L7AqMDiH8SVaeMg2rQXwqx3m0Y2ps99dfaqA1kqFVmR7vrDNDq2lbun1qkHohaVSv5OCPDfCrZFOy9aD7d6OFKG5nKSBIfq+9+eUf7Vyhe2vV4VPkObk4ohTZmtirPzCeIc+VD BS4LsFoO 7Dl3pfMAxWiwG8kyVVDcAlD66H0bdq6bysXt9jPd+4pdZRptEJqYcIew6qOc3dMbKzwf3FFBWp3oJrZguwv7xwqJ36bcKx0zQ1p8rP/JQM409YVCLxGgnvtwMkgnC5g3TmEj9eW1C/qBDQEGKYrgF5Us9IX/ou5Ej7LTjfMtX28Hx6gONeq79wajbL3pSvPG1GxzCwucNz0LGJlAS/BzFrwvwH9eI4DSI0JMg6SNTXpjSl6nB06moEaayf7V7Hvr3caasHndOpoH1zvubSP4YjrbTMomh4bejG13xPG8By1OTd68M9OWgT2VAVBVAyr/NXFA1G/rsu9X+Nq8lfyZrH2/jU4TogE3mojpMZl9DLVZOWZZ9ZapfizwRuZqXbvjC2NsfkQEn5VcDkp/lmCIknb1sNH8fBfWTMAmg7/4kGzJIFNTlvDYjFp3PaXb6ZeGydF2TrJ/V9VC9BhzkhNxSWMxRmVk/JJDM3aZ7FtQ2a63N4lffnFA5Dd5TggxFfX9UuoXFcgw4Xe8GSNzf+8ciYwATqIumiIq7Qlv74c2yTGEMCxDP8rekqn12VQbRZKC4lSKxo0C+HjToj55gw/7D+vfWEcqtHl2ccuVKri64MTkbXaE81HO465TRV+t7CyxFgEj9k63MPzxP374faJVRoXRmsX1cUo3BlSMWdh9QcGnQ/8zaSU3HkN0rJoKMlJmbYGjD7y4QpOJu9uSsXMm2lXa0pA== 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 10/4/2024 6:40 AM, Alexander Duyck wrote: > On Tue, Oct 1, 2024 at 12:59 AM 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_task.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_MASK) >> #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 bit and >> + * order of a page. >> + */ >> + unsigned long encoded_page; >> + >> + /* we maintain a pagecount bias, so that we dont dirty cache line >> + * containing page->_refcount every time we allocate a fragment. >> + */ >> +#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) && (BITS_PER_LONG <= 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 line >> - * containing page->_refcount every time we allocate a fragment. >> - */ >> - 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_PFMEMALLOC_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_PFMEMALLOC_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? > 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.