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 98DB6C4345F for ; Tue, 16 Apr 2024 16:22:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DCC06B0092; Tue, 16 Apr 2024 12:22:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18D936B0093; Tue, 16 Apr 2024 12:22:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 054636B0095; Tue, 16 Apr 2024 12:22:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DBA966B0092 for ; Tue, 16 Apr 2024 12:22:19 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 94D49A1D3E for ; Tue, 16 Apr 2024 16:22:19 +0000 (UTC) X-FDA: 82015912398.19.CD45B1C Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf09.hostedemail.com (Postfix) with ESMTP id AAF8C140020 for ; Tue, 16 Apr 2024 16:22:17 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YHuJAaqf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.210.173 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=1713284537; 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=AZ4By8kx0gFset4vqlanrt2cwjHe/0P230mvGWNMhPQ=; b=J17xAbfYpA4uYwjrt6PJpjmmeki5NATlW3y4Au6r9UQtuBv5/RjDgyAVdWvgbb6Qv7cMgA cTH4QyCHdoBQAMhTYFJXtN1gPScBpZMry6VYCyylZXkK/RBriK0cSxkQ0NvbUOR947/fH6 ENHqZL4itNBawEC16NCNbZQLIz+Ranw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YHuJAaqf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713284537; a=rsa-sha256; cv=none; b=aNMswYchaK2L2rIXLN+PuJWT3cyStMTsZYVfyEXywHih17unC+pNJEXV+KCIphEbC2hxmd 0l7BsvFnZmoehwq8zyQ2yzOExJ8D6lZ86HnoVuZesWdI3pQkcuP7YF7Lr1OzaswoHgM3ly IIeqPhmCqgEp/iAd/J7ZSzjH4FAsJQc= Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6edc61d0ff6so4218569b3a.2 for ; Tue, 16 Apr 2024 09:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713284536; x=1713889336; darn=kvack.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=AZ4By8kx0gFset4vqlanrt2cwjHe/0P230mvGWNMhPQ=; b=YHuJAaqfdVjEHY1b9YyESQPcwu683arnvGu0n0jwPI03ufBeANas/JGNgv8JPuEf2E J03h/h85McP4G4OX+S+p7SOYPEJrM7WsPHM4pU4Il0EQupEISoDRDGUkNBv9aPSHd8Ud OTHkv8Py71GnRQKcv0u9hZy01mt+jIjdFuXI9j1ZaifgNtuG1f6Bu+JoM/Cqi2+EvGNY b5fM9DX25ClHhB1SMHRYZluVOGwVI/FtcNkgmKRBQfX6FanVtaWWMVD+WceFVSmjJ2Cl 3hq8Vga7g7V1yvDyu5bW85jFSWA/u1zaMeagoj/E3aNez7YInYoGrh2J7G0DpzMJH9re ARiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713284536; x=1713889336; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AZ4By8kx0gFset4vqlanrt2cwjHe/0P230mvGWNMhPQ=; b=jeeQJ6b9ehtGZyA+z79fBO4JzHkgHG87oUopzAl9hjAYstQ+crQo7Kbw1wnVESjuTM fsw0tcMOwI9JDZ1fKSDDDSDdke+sd7hqn3wXRUTrm8a0+WMZlt/3InJSSmtNlBtPREtV o2elnkSiyc2kRkCKeB+vjOszuKPmYh/9Cwg8mIMwN+jr2/A6Mw4tjmig7DsxoU0R+waP EKvfG+41qm7APtjmETQaj3Slpr0xU2pB1c8ETlNc4KZp8buhMx+p0WRhJfYVWAE5PP1/ ENHiAWkWZ//rroR0JZATE4zT8NUpke0x2mEqd30kDtaZC2tKkvA4LBFLrEIbxyjuWKiG 9crQ== X-Forwarded-Encrypted: i=1; AJvYcCWJbDjip56E/Y32Tz4iX2E/bSv9UydpqsEdgu87x6v3jFkv653BpXd7pWiXIEVhqT9gfbaZPJI+cf6mY0YLp6SBcpc= X-Gm-Message-State: AOJu0YxEokH561obnE7Otah5/sjUI3FtSSDKT5MC29TFz2a21wUrobTh SnPG/zCTD4/V8yIvulodqJYKKBSApSp7PiXDK0BtYyASzGC9BGcx X-Google-Smtp-Source: AGHT+IEUcecI89KJcxO4bdyAEaKuPOEWjzAq92Tsddkmk7lM8Dxh6sxfWs7GUP8/jFDeTzbXdw94fg== X-Received: by 2002:a05:6a20:1a91:b0:1a7:802d:f67c with SMTP id ci17-20020a056a201a9100b001a7802df67cmr13606350pzb.53.1713284536293; Tue, 16 Apr 2024 09:22:16 -0700 (PDT) Received: from ?IPv6:2605:59c8:43f:400:82ee:73ff:fe41:9a02? ([2605:59c8:43f:400:82ee:73ff:fe41:9a02]) by smtp.googlemail.com with ESMTPSA id q23-20020a631f57000000b005eb4d24e809sm9151661pgm.34.2024.04.16.09.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 09:22:15 -0700 (PDT) Message-ID: <37d012438d4850c3d7090e784e09088d02a2780c.camel@gmail.com> Subject: Re: [PATCH net-next v2 09/15] mm: page_frag: reuse MSB of 'size' field for pfmemalloc From: Alexander H Duyck To: Yunsheng Lin , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Date: Tue, 16 Apr 2024 09:22:14 -0700 In-Reply-To: <20240415131941.51153-10-linyunsheng@huawei.com> References: <20240415131941.51153-1-linyunsheng@huawei.com> <20240415131941.51153-10-linyunsheng@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AAF8C140020 X-Rspam-User: X-Stat-Signature: s3e64c6s3nxw1dd4rm31d5diqet7d6xw X-HE-Tag: 1713284537-293286 X-HE-Meta: U2FsdGVkX18rQH1Zc568k88Fu3Hog6lfuew/oD9/RjMuIBFewrRBnIibtpgTPMrACgC98WsAsRCcKCrsIou5AisZYuCfRoycd0tbcq+uOfYsfKMR2x2JSasgB8k/oHty1XSueQPttgRh2vHeclmDyF+orrxGTr4gJbOsbzmPN+SatNt3cDgyOOBysJ7dhpd3HreNCFH17IQKN1tS5Me8VkyiTkv6oXVgo6ofmebP5uY2NI065IRneKJnHZ3+V0//veY0L1/P11F4D8xS+pKy1ujNnZAtFfSi/wopGfYUY4cD1i+BZqznNO/xU3EiLYKnJ2gdvsPX6qR32mUDN5kc2WY4wEVaq1ZVBjhEVqbJOyUnxSLOHquQkXVoPxllzLj9q5CI/ra4waEdfSk8Df6PmwdTX6i+SJOKdeTcSkQSKEdCfWatPsO6Db58UES/+mKXBGUKgMpebMVzC4ataHedg7uEXs7cFPhLyHl0ztjNZy4FcAUJ1jInqaxWfjkN3CqvxFnYXLQiVQ4qDUaJ9XAOZscA1QjVFMQggUKCgQIuLHfuGsrCgIihkQZCwJnaQS2rHhvKJ3ByVqf7+27zlJo1/yzfE0gqn7iRKZsuQmVt867fRXpEgxFRgoIrgSf6M6f7bsuIHA0j/ujXnxVkKcLg79aydd3RSmuVMCV2pMWBmwi3yGfOJWPU70uD7BCbcfHsG3pUyYqORg+0AeVXyTqVoh23exFhxq1IhALdR2F2H0EduLRPC/kn1+rvD2eRODbGP1HDL79fIASdpe3S7u6UMzCH7OQH6YIEt3K0+GPYYT62PlQV9fX3hK8rHXVbSN2IpM30nvk+Ka5sKB9NtmTqpUjLWYlwiH0WYjQMBGuqzpr5LhDKGhjZ0fVFSchqwsDbnY6SxF4Cchz9dfL2pezeCtqdPV1xayaDBkjvrI2rKG6+PntBVq/aRGSz2CKmKN393b7OEsDYpWRfxeQbfsX nybS3iYf z/47OMwcic9ucLS0NjGQmXc+CNmsd9uTk6VPeHRQ7qGvFJjgLgrmsvtvb9i8/+jMTfjPcJCF/BUwAL3q0Mj3YOHShULp8XCTuZCK4TOr4U2kLFRRJm91kwqp+06x9FkZ37bMvz5eZSIGvbkPBuVc45nJJatM7tGHp1BBJMJnD7wQ8pQZwlFRDZs868sc9posbeGotpiCE26xLPqYsQnUML2OJ7jO7PgAhzDFN/Fhf7PRWbOv10PT4/ZDkAHSNLG0fwxcneHfBfE2rsNMZ+bYC7MFA/XczhfGQ3vC4GnBQeYyTERzgCa0lttdyQrKEsEWTMpyOCE+sN8tprnoNcI4mV45Eu1TBx4OtW3mPe882/0Kh9ax0y3xd0FTqkaAmk6YYcVMn3OZAZYcgsrQarbgCYrtts8pQVZLOGVbXUEZVz9iAK+UKVNiiPQOxzn/e2uwylRh0yOiPtDBYNKsJNKtQx4jcfr6AKhbszp42nOXqwvpn6sQwbNxdjCixaE4JEUnpjppWTBy8xZMqLHHEHeRIV8AaaomRo0Ou/ZHs1SBkiWe9A+k= 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 Mon, 2024-04-15 at 21:19 +0800, Yunsheng Lin wrote: > The '(PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)' case is for the > system with page size less than 32KB, which is 0x8000 bytes > requiring 16 bits space, change 'size' to 'size_mask' to avoid > using the MSB, and change 'pfmemalloc' field to reuse the that > MSB, so that we remove the orginal space needed by 'pfmemalloc'. >=20 > For another case, the MSB of 'offset' is reused for 'pfmemalloc'. >=20 > Signed-off-by: Yunsheng Lin > --- > include/linux/page_frag_cache.h | 13 ++++++++----- > mm/page_frag_cache.c | 5 +++-- > 2 files changed, 11 insertions(+), 7 deletions(-) >=20 > diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_ca= che.h > index fe5faa80b6c3..40a7d6da9ef0 100644 > --- a/include/linux/page_frag_cache.h > +++ b/include/linux/page_frag_cache.h > @@ -12,15 +12,16 @@ struct page_frag_cache { > void *va; > #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > __u16 offset; > - __u16 size; > + __u16 size_mask:15; > + __u16 pfmemalloc:1; > #else > - __u32 offset; > + __u32 offset:31; > + __u32 pfmemalloc:1; > #endif This seems like a really bad idea. Using a bit-field like this seems like a waste as it means that all the accesses now have to add additional operations to access either offset or size. It wasn't as if this is an oversized struct, or one that we are allocating a ton of. As such I am not sure why we need to optmize for size like this. > /* 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; > }; > =20 > static inline void page_frag_cache_init(struct page_frag_cache *nc) > @@ -43,7 +44,9 @@ static inline void *__page_frag_alloc_va_align(struct p= age_frag_cache *nc, > gfp_t gfp_mask, > unsigned int align) > { > - nc->offset =3D ALIGN(nc->offset, align); > + unsigned int offset =3D nc->offset; > + > + nc->offset =3D ALIGN(offset, align); > =20 > return page_frag_alloc_va(nc, fragsz, gfp_mask); > } > @@ -53,7 +56,7 @@ static inline void *page_frag_alloc_va_align(struct pag= e_frag_cache *nc, > gfp_t gfp_mask, > unsigned int align) > { > - WARN_ON_ONCE(!is_power_of_2(align)); > + WARN_ON_ONCE(!is_power_of_2(align) || align >=3D PAGE_SIZE); The "align >=3D PAGE_SIZE" fix should probably go with your change that reversed the direction. > =20 > return __page_frag_alloc_va_align(nc, fragsz, gfp_mask, align); > } > diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c > index 50511d8522d0..8d93029116e1 100644 > --- a/mm/page_frag_cache.c > +++ b/mm/page_frag_cache.c > @@ -32,7 +32,8 @@ static struct page *__page_frag_cache_refill(struct pag= e_frag_cache *nc, > __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC; > page =3D alloc_pages_node(NUMA_NO_NODE, gfp_mask, > PAGE_FRAG_CACHE_MAX_ORDER); > - nc->size =3D page ? PAGE_FRAG_CACHE_MAX_SIZE : PAGE_SIZE; > + nc->size_mask =3D page ? PAGE_FRAG_CACHE_MAX_SIZE - 1 : PAGE_SIZE - 1; > + VM_BUG_ON(page && nc->size_mask !=3D PAGE_FRAG_CACHE_MAX_SIZE - 1); > #endif > if (unlikely(!page)) > page =3D alloc_pages_node(NUMA_NO_NODE, gfp, 0); > @@ -86,7 +87,7 @@ void *page_frag_alloc_va(struct page_frag_cache *nc, un= signed int fragsz, > =20 > #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > /* if size can vary use size else just use PAGE_SIZE */ > - size =3D nc->size; > + size =3D nc->size_mask + 1; > #else > size =3D PAGE_SIZE; > #endif So now we are having to add arithmetic operations to the size in addition having to mask in order to read the values. That just seems like that much more overhead.