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 19066CD1296 for ; Mon, 8 Apr 2024 16:12:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82F376B0083; Mon, 8 Apr 2024 12:12:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DE376B0087; Mon, 8 Apr 2024 12:12:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A6766B0088; Mon, 8 Apr 2024 12:12:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4AFCD6B0083 for ; Mon, 8 Apr 2024 12:12:09 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CF7D51608ED for ; Mon, 8 Apr 2024 16:12:08 +0000 (UTC) X-FDA: 81986856336.15.E34A9D1 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf06.hostedemail.com (Postfix) with ESMTP id E7E54180015 for ; Mon, 8 Apr 2024 16:12:05 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=d3SNCzAZ; spf=pass (imf06.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.43 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=1712592726; 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=uENSkFYk7LJQAn7mCGOHXBkbAqtqsej2uPu661a41kA=; b=an2p5/hTUijwB4GE6LUVD2cW9dp0VmLhSIdUDRSi0rrvYTuYOwtuqhmpClZVYHEKHvIHtL 6IP15+yanjR9A7zoc+V/ID9ls3mGwBvpJQxIcDGAQeeUIJfYT7U5XShb0ie4XJNR/UNraP PZNUR41hLI9VV6YbnBgQBdhysw8P/8w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712592726; a=rsa-sha256; cv=none; b=bgneJi7ILcMB2/+WS5KxPBvJttUZihWmj8LtjFsKqLij3ayev1G8gdcKTaQGBzCQyKfnNu ELjZ/G/BU00x+Dgaq394shTikeIco53VSorfHoJcWnbEQXOXA9o3TJrDQtOMMH8EMftBg2 4wlttQn54whRq2c0eWYYJIiPKCmkd24= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=d3SNCzAZ; spf=pass (imf06.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-416511f13aaso10674155e9.1 for ; Mon, 08 Apr 2024 09:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712592724; x=1713197524; 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=uENSkFYk7LJQAn7mCGOHXBkbAqtqsej2uPu661a41kA=; b=d3SNCzAZfTniw93O77TyVbIHPB6yCa93srUMdRZrWK6FoPWA55mwlkjiFEfpKspaxB yjQ1/9McRlZHP25d/OOpp1ePUBDXoK/hnCt8UOev+2g/cjHkLzfYxzJWMnFA8VqNNrFb RYoEHZ1QHvZG3wmXq2ZltbHP1d9Nxh57eeKPehX+g2n6Pg9bK5oBwuTk/A6tvpUwv5P5 ZqrEacx7U1m+kICkjaf0wtx+yUoXaGcrPja+5aW7Ov01tSkmiOj7Jwn4/WZQcIyAwsZy Gch0QEwbDovvx4bbFLx4LHLsTJCcMynd0JH3GShSUBiz9GWMEaP5iIiDx6g/b8ILzCN8 8kZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712592724; x=1713197524; 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=uENSkFYk7LJQAn7mCGOHXBkbAqtqsej2uPu661a41kA=; b=UdvBXyelFn6NTsM82ZgXzrk+dVI9y4m38C4j6q0Q4HX2v4UAjpfY+/aKsDttR82a7n SYQwxsdHu7rHyuoSSpzIaBWQ2FP/DFmeBoy1EcLCoGmXCnrlqg3qs9IPJiublC+ps76a 58UX3KAsgYH+LkXnBZ4xXrFXnc4LEP4u+VlWyM9Z0Obi+Vg+HbzOPEBdhVGPI5+ur0re 2HwpKxV97Y3XfaGSY3FSUEg7Gcx6jrai+C9OYA8CZdExYRfVfe+ah3rYEaMc0J9FCIBv O1OCIi+cFmVFb066/zpG1n0Ysbd3TOrcoOldeZtOCBLHsDBPjXARUPbtU/TICXFZPszk FBUA== X-Forwarded-Encrypted: i=1; AJvYcCWSY48M7OOz5NdAhfVUn1clKoXbf8Qb/v81iT5SqqmjZSpOg4KfptoAOEARdMmhEs75948nibEV1oEkRgXxmTe1UsU= X-Gm-Message-State: AOJu0YxcgtH2iVR8ZgehDCvkjVMThn/Sx1Kxb1f7FBhSnbXS/WYrBs/J znmMzOnpVoeX7M14DmtJpBqEJT8vb1tMEJ99LrgQOS7oHb2CZtJBa4mfFcSdaOhUsnTMfep/nO0 nABp22DMw/IzU0wHpcs/CqQCHd18= X-Google-Smtp-Source: AGHT+IFAIaTKgph22acfUSjo2dBjVYyCDxQyK2ImPqk6Uch9Zdywdu/wpWrNnadC24R9520/rJ3mpRxVjsyKkoYeKKk= X-Received: by 2002:a05:600c:45cc:b0:415:45ea:9922 with SMTP id s12-20020a05600c45cc00b0041545ea9922mr7458671wmo.35.1712592724107; Mon, 08 Apr 2024 09:12:04 -0700 (PDT) MIME-Version: 1.0 References: <20240407130850.19625-1-linyunsheng@huawei.com> <20240407130850.19625-3-linyunsheng@huawei.com> <43d99616cd4a2a6fce6a6b97f73d08ebc5361a61.camel@gmail.com> In-Reply-To: From: Alexander Duyck Date: Mon, 8 Apr 2024 09:11:27 -0700 Message-ID: Subject: Re: [PATCH net-next v1 02/12] mm: page_frag: use initial zero offset for page_frag_alloc_align() 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-Stat-Signature: mtu4h18fhcgpmx7a51698x47uf5ck4fy X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E7E54180015 X-Rspam-User: X-HE-Tag: 1712592725-132085 X-HE-Meta: U2FsdGVkX19MT3Mr+Z+BYeB1jtSbdnCKRAKQD+P5y5jLHIH7cx+ZCs+/5rluEgj5CXZs2ni1DkA0ZndW8EfVyS/hVf7+PM/VCX7ea73+UEBaih8j9OLtOvs6N+fHlL8mFDaZJWe+Tfe1N2bFYLFpA7S6Oao78umeAPvrY10qOvJVZttBgt2w4SoT8U/18jaEPNXquV5r9Dj6/rFhAUYVbRLUogHXmozLS9Yuni5DinWsaEhzUgV2VHjjZjDIzZoHb4bFM7t7mwPUr3625u7epB+FO5zmoGcMVRlrJ/960wFq0h3yyBWm2Ph7bgQgT2ZSCkZNNeiAkhxl6c663j2PMWVJBRW3qXbHPPrZgQ9CI38GKJaeJE+iMvB40870blrREGcKusMImXdUMPen8c1ZPzkeaUCyfrbjtEHJi9i5OjJS4Owo9E5C1GSBs8HtxssUKbW/iJtOELMK5otY4Vo13NtAmwQEeagl53xqvUS5HmfEY+6Tq7zv7+6NopE5j/292AINdLMokuhU7EMZJGulaz0IHB3YRJFFJTvmIMy59Q8PIiezWmtfvuKHKvGorH9yL4FJIbMyDP6SWjT1I9WybTBKu+dELyRE/Njp1wSWIcGilnOUgreABBNVWv4lijcGbcKIb/9Z/Poy6WBszVzgY30c6kj/Vib5Ao/EaHUGU5mmW/7CPHDgV1Z+Ri4fPGw9k4ImILtiZOQMmUByyCK7uONcUxBpPSn2c65bYzdLnz1udGoSfongvIOBmdvIXzY5kk2g1wjRJYVrmUcx4k7r9dZXYuPgNiCD2ygxdXBPoNp/BUxSB2v8OA8dWIJ9+5IIJOioPmgdTHnEf+qNw7hzaSby1S2y5kwXlhkRfx1hGzFDIhAsVRghCLAjK/ngRotMRpMfeyRe1a7LgP0W+gCgkbIwMikLGpmbbaJmG6kpnEMP9hgeEt2r5p9xKZSXLuy222ly6Wf2TcQxQc2nYtc kQAzuu3+ bBsLR03YhuEuAkIlXDWYLOdz9XtbL+evc/mwMY661J8W2b1eZjOQwU2s4A9qI35QHEM7CJV/PaJBplSZjz8SWPVnFpCAFcQ0JjtJXkeeoeceVJKKpAadr9VPBjoxjVvt8kVnQ1WWHY7YNCSlHTEOZF1rI8bxlHgD1vssjGrgbsWf5jdb188sGltoFc8mOKBA2DestfQNMylp+gUoDlmvZvWytAzRafqdKkBuvMvxIH/eCJeGBOQILDlyGoCgvGTX8vy8MG9ZCAzTv3ElzFA8fgSKx6mkfB1Z0ErRy30kQia+UX4gT8mvqqUjRno17oAlpuOwqN6DlSul9eFGIu7vhgkUCoOnQp6NRTlZDjg5GzIAjj79r6jfSbrwxOQqvdPlmgduRfLOSzWulPJ3eK7vZPEyNIDKqGlPjjm/AHWU8RBhmjyTyR9qCSqhHgS8T4BerNo1GQPhRGdcM01hzgP6OqrxmswlFDSK3g6dhKUt0bOq9UTlbnsimUnQ9rOChHxK/9IU+jbok0TdkJQxI5AYtFAyr9IhT9Q9ARbZp 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, Apr 8, 2024 at 6:39=E2=80=AFAM Yunsheng Lin wrote: > > On 2024/4/8 1:52, Alexander H Duyck wrote: > > On Sun, 2024-04-07 at 21:08 +0800, Yunsheng Lin wrote: > >> We are above to use page_frag_alloc_*() API to not just > >> allocate memory for skb->data, but also use them to do > >> the memory allocation for skb frag too. Currently the > >> implementation of page_frag in mm subsystem is running > >> the offset as a countdown rather than count-up value, > >> there may have several advantages to that as mentioned > >> in [1], but it may have some disadvantages, for example, > >> it may disable skb frag coaleasing and more correct cache > >> prefetching > >> > >> We have a trade-off to make in order to have a unified > >> implementation and API for page_frag, so use a initial zero > >> offset in this patch, and the following patch will try to > >> make some optimization to aovid the disadvantages as much > >> as possible. > >> > >> 1. https://lore.kernel.org/all/f4abe71b3439b39d17a6fb2d410180f367cadf5= c.camel@gmail.com/ > >> > >> CC: Alexander Duyck > >> Signed-off-by: Yunsheng Lin > >> --- > >> mm/page_frag_cache.c | 31 ++++++++++++++----------------- > >> 1 file changed, 14 insertions(+), 17 deletions(-) > >> > >> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c > >> index a0f90ba25200..3e3e88d9af90 100644 > >> --- a/mm/page_frag_cache.c > >> +++ b/mm/page_frag_cache.c > >> @@ -67,9 +67,8 @@ void *__page_frag_alloc_align(struct page_frag_cache= *nc, > >> unsigned int fragsz, gfp_t gfp_mask, > >> unsigned int align_mask) > >> { > >> - unsigned int size =3D PAGE_SIZE; > >> + unsigned int size, offset; > >> struct page *page; > >> - int offset; > >> > >> if (unlikely(!nc->va)) { > >> refill: > >> @@ -77,10 +76,6 @@ void *__page_frag_alloc_align(struct page_frag_cach= e *nc, > >> if (!page) > >> return NULL; > >> > >> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > >> - /* if size can vary use size else just use PAGE_SIZE */ > >> - size =3D nc->size; > >> -#endif > >> /* Even if we own the page, we do not use atomic_set(). > >> * This would break get_page_unless_zero() users. > >> */ > >> @@ -89,11 +84,18 @@ void *__page_frag_alloc_align(struct page_frag_cac= he *nc, > >> /* reset page count bias and offset to start of new frag = */ > >> nc->pfmemalloc =3D page_is_pfmemalloc(page); > >> nc->pagecnt_bias =3D PAGE_FRAG_CACHE_MAX_SIZE + 1; > >> - nc->offset =3D size; > >> + nc->offset =3D 0; > >> } > >> > >> - offset =3D nc->offset - fragsz; > >> - if (unlikely(offset < 0)) { > >> +#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > >> + /* if size can vary use size else just use PAGE_SIZE */ > >> + size =3D nc->size; > >> +#else > >> + size =3D PAGE_SIZE; > >> +#endif > >> + > >> + offset =3D ALIGN(nc->offset, -align_mask); > >> + if (unlikely(offset + fragsz > size)) { > > > > Rather than using "ALIGN" with a negative value it would probably make > > more sense to use __ALIGN_KERNEL_MASK with ~align_mask. I am not sure > > how well the compiler sorts out the use of negatives to flip values > > that are then converted to masks with the "(a) - 1". > > The next patch will remove the '-' in '-align_mask' as the 'ALIGN' operat= ion > is done in the inline helper. I am not sure that matter much to use > __ALIGN_KERNEL_MASK with ~align_mask? It is a matter of making the negations more obvious. Basically you could achieve the same alignment by doing: (offset + (~align_mask)) & ~(~align_mask) rather than: (offset + ((-align_mask) - 1)) & ~((-align_mask) - 1) I'm not sure the compiler will pick up on the fact that the two are identical and can save a number of operations. Also my suggested approach is closer to how it used to work. Technically the one you are using only works if align_mask is a negative power of 2.