From: Alexander Duyck <alexander.duyck@gmail.com>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Subject: Re: [PATCH net-next v1 02/12] mm: page_frag: use initial zero offset for page_frag_alloc_align()
Date: Mon, 8 Apr 2024 09:11:27 -0700 [thread overview]
Message-ID: <CAKgT0Uf9hWmVjHfrX6yM_LgX6D5m+ktFiJatMhOhuHpADghh4Q@mail.gmail.com> (raw)
In-Reply-To: <cccbddc2-de64-46f9-7d71-60185d364f73@huawei.com>
On Mon, Apr 8, 2024 at 6:39 AM Yunsheng Lin <linyunsheng@huawei.com> 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 <alexander.duyck@gmail.com>
> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >> ---
> >> 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.
next prev parent reply other threads:[~2024-04-08 16:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240407130850.19625-1-linyunsheng@huawei.com>
2024-04-07 13:08 ` [PATCH net-next v1 01/12] mm: Move the page fragment allocator from page_alloc into its own file Yunsheng Lin
2024-04-07 17:42 ` Alexander H Duyck
2024-04-08 13:38 ` Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 02/12] mm: page_frag: use initial zero offset for page_frag_alloc_align() Yunsheng Lin
2024-04-07 17:52 ` Alexander H Duyck
2024-04-08 13:39 ` Yunsheng Lin
2024-04-08 16:11 ` Alexander Duyck [this message]
2024-04-09 7:59 ` Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 03/12] mm: page_frag: change page_frag_alloc_* API to accept align param Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 04/12] mm: page_frag: add '_va' suffix to page_frag API Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 05/12] mm: page_frag: add two inline helper for " Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 06/12] mm: page_frag: reuse MSB of 'size' field for pfmemalloc Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 07/12] mm: page_frag: reuse existing bit field of 'va' for pagecnt_bias Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 09/12] mm: page_frag: introduce prepare/commit API for page_frag Yunsheng Lin
2024-04-07 13:08 ` [PATCH net-next v1 11/12] mm: page_frag: add a test module " Yunsheng Lin
2024-04-12 13:50 ` Simon Horman
2024-04-07 13:08 ` [PATCH net-next v1 12/12] mm: page_frag: update documentation and maintainer " Yunsheng Lin
2024-04-07 18:13 ` Alexander H Duyck
2024-04-08 13:39 ` Yunsheng Lin
2024-04-08 16:13 ` Alexander Duyck
2024-04-09 7:59 ` Yunsheng Lin
2024-04-09 13:25 ` Jakub Kicinski
2024-04-09 15:11 ` Alexander Duyck
2024-04-10 11:56 ` Yunsheng Lin
[not found] ` <6517b5ae-e302-4cbe-8a4c-716e604822ce@redhat.com>
2024-04-10 18:19 ` Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKgT0Uf9hWmVjHfrX6yM_LgX6D5m+ktFiJatMhOhuHpADghh4Q@mail.gmail.com \
--to=alexander.duyck@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox