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 4840DC67861 for ; Tue, 9 Apr 2024 07:59:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4DA16B0092; Tue, 9 Apr 2024 03:59:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFDFE6B0093; Tue, 9 Apr 2024 03:59:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC52E6B0095; Tue, 9 Apr 2024 03:59:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9EA066B0092 for ; Tue, 9 Apr 2024 03:59:55 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 352031202B2 for ; Tue, 9 Apr 2024 07:59:55 +0000 (UTC) X-FDA: 81989244750.28.CD8DBCD Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf25.hostedemail.com (Postfix) with ESMTP id 0B192A0038 for ; Tue, 9 Apr 2024 07:59:51 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712649592; 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; bh=UrFAD5JsGDL8g6tECNQgZkMl+egwmYqzpV4B9cfujrE=; b=xwZIPG9MVhzwZuMkiyYA9IwgqLGtZobHpWTHU1p4sW3sKO0BFbMVALGBw10OBCb03uAtE0 eQRZLOyiJwJXKInjmLvPQEhEMESmWj+h8NrEA++J22RRrxSR7hbm5eg4hDbzyBFg2YEfrZ 1I03npN8m2JtLxxz7SshlKNy/GLRc5Q= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712649592; a=rsa-sha256; cv=none; b=DQjNy6yLTP4KI7Jy4tf5bj36/WL4CY6bNh4O2VlWfu20Plrx5dGgXbfwCHHF+9xDkcRt95 CmO8VFzJnwt/Bn3zyrVgxFGODvr7KkO8y8HxKeaAYfZEqdhB50fUwtKui8+iNSmHqt9teA HJq9+9NB2UkCBv74dFjOGtV4FzHbBQw= Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4VDJFs4TCzz1R5Sv; Tue, 9 Apr 2024 15:57:05 +0800 (CST) Received: from dggpemm500005.china.huawei.com (unknown [7.185.36.74]) by mail.maildlp.com (Postfix) with ESMTPS id 727B31400CD; Tue, 9 Apr 2024 15:59:47 +0800 (CST) Received: from [10.69.30.204] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 9 Apr 2024 15:59:47 +0800 Subject: Re: [PATCH net-next v1 02/12] mm: page_frag: use initial zero offset for page_frag_alloc_align() To: Alexander Duyck CC: , , , , , Andrew Morton , References: <20240407130850.19625-1-linyunsheng@huawei.com> <20240407130850.19625-3-linyunsheng@huawei.com> <43d99616cd4a2a6fce6a6b97f73d08ebc5361a61.camel@gmail.com> From: Yunsheng Lin Message-ID: Date: Tue, 9 Apr 2024 15:59:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500005.china.huawei.com (7.185.36.74) X-Rspamd-Queue-Id: 0B192A0038 X-Rspam-User: X-Stat-Signature: fbyd4h3aprcjkywotemwep8hfo868t97 X-Rspamd-Server: rspam01 X-HE-Tag: 1712649591-583555 X-HE-Meta: U2FsdGVkX197ZvMn+MDa/JkUTntG34VuqkbLey+pk7i3rLI1KvslkPKvX6mEPQCQWs4asrN9ZRwlvBljplMksEW+8MCNwJu6e213oHgPR5bfZU3+bVAaXQJCAOVc0yTXd41oBz8xJuIQIYrSARx0SARnv4BVD5kwr14W7ye/q7ta97fyj5YigcMhXqJaM4eVxR9LnpqCmMvvrZ5ruOsfbk8ON54zeSbY+N+MiTO00pcFMO9Utq2qp4wkDJ+xyyOvV1/cXI+ZyMRakd7tsMXIvRxU3xiDav1TG+gYgJ1WHmJ/GrIRjyC7TwfPhFFVv/eNTctqA1UygE2Arg3tsKz3uG+Ry2x3cXTg4J8qSGY25pcs9Km+L2fh2DQx7wELAmXqomVXl01O++Uqy/zRvG42LVSvV0bQpv/zIJpusbT5h5SUrTu+uJJMj1nEJ2mbWqxsTreeFTym/ssMxwZ4bVYG+52lRvw3dm+Bl7ymnfH0PLBCGGs4uqsrP5c9Ofks6iEj7Pp3PTznoc+ihmS3/iWL7JHgnxuHwmxFv6pg9HqN+WhWHNLB/1xeAlOU64DHbj0Hv7cNYlX72vZELJm1z9iBHNB5WcAPAzvOovj7vB+teMymMPoLgmErYkbiklCFCGm1grcYe6C04ZQMyUgjA3P3Na6wTV5akJn8pTy/YvjVaym1YLogPGYaQu62heIqjh2/v+T7J7ExI3rQLOVIZ7/MT8KMglh9HCLFapD0xN6f8y9ZomE+N36hNULB2jdQlcBPdNNJN3mSS5LSnrZKIdgp6M5Y3706u9AF8kAuDdSav1ZqwdlTAGDxXK7/ncl4HuOpfEbltwnBxxZ+Jj6wDm/W8trfUJYKOJdYaUMkU1iO6/dZSBsLn4OoMJ8PYVKRJnbF4RrC1fEwDh5MlAC3GzKraD5hmY4s/pH8xHI9LhFrig95m+Rh7BBecourz8fS7qeS7vbHpdf3/bzdLoXAHNA j8vUelP5 yYQPBm5T8SotmWWKbrT+1RqiocJttiIsDIPzF9DoEsCrYqyds2ElaaXKx9y4DqVrylTz1eB0UOi+cw3HgZOrS3bNeM8iA8ZdIRlhSX02DDpybdKsU8O+UhTxFvRcqNVCcEz0njAP6o0Qny9Hi/Pw7xTm3yIxfsCOfnsKcui3P1uZxCOjwCd93jJoZjs4OXsCdTKg0K3DgKYMMIyXToDHW6kKzQLlo9j3HGN8qxweXZycVHdDznDcBnwzxMgeKH0ZUjdGjlbxrV7wmfhCJCe68fIK7S/3ehgUjH8b47ll1pXihUl4EUEMMrAhOLka8YU1E7cIkTAMxKQIiY/JjKO9emVQRDcYvd5c+UHw6a80n8YMcuPZn2DIzh/Y2rCAjlYT39t4L 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 2024/4/9 0:11, Alexander Duyck wrote: > On Mon, Apr 8, 2024 at 6:39 AM 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/f4abe71b3439b39d17a6fb2d410180f367cadf5c.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 = 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_cache *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 = 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_cache *nc, >>>> /* reset page count bias and offset to start of new frag */ >>>> nc->pfmemalloc = page_is_pfmemalloc(page); >>>> nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1; >>>> - nc->offset = size; >>>> + nc->offset = 0; >>>> } >>>> >>>> - offset = 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 = nc->size; >>>> +#else >>>> + size = PAGE_SIZE; >>>> +#endif >>>> + >>>> + offset = 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' operation >> 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. In patch 3, we have below, so the above trick is not really needed after patch 3: @@ -94,7 +93,7 @@ void *__page_frag_alloc_align(struct page_frag_cache *nc, size = PAGE_SIZE; #endif - offset = ALIGN(nc->offset, -align_mask); + offset = nc->offset; if (unlikely(offset + fragsz > size)) { page = virt_to_page(nc->va); @@ -131,7 +130,7 @@ void *__page_frag_alloc_align(struct page_frag_cache *nc, return nc->va + offset; } -EXPORT_SYMBOL(__page_frag_alloc_align); +EXPORT_SYMBOL(page_frag_alloc); ... +static inline void *__page_frag_alloc_align(struct page_frag_cache *nc, + unsigned int fragsz, gfp_t gfp_mask, + unsigned int align) +{ + nc->offset = ALIGN(nc->offset, align); + + return page_frag_alloc(nc, fragsz, gfp_mask); +} static inline void *page_frag_alloc_align(struct page_frag_cache *nc, unsigned int fragsz, gfp_t gfp_mask, unsigned int align) { WARN_ON_ONCE(!is_power_of_2(align)); - return __page_frag_alloc_align(nc, fragsz, gfp_mask, -align); -} > . >