From: Jakub Kicinski <kuba@kernel.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Matthew Wilcox <willy@infradead.org>,
kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com, netdev@vger.kernel.org,
Eric Dumazet <edumazet@google.com>,
David Howells <dhowells@redhat.com>
Subject: Re: [PATCH] net: micro-optimize skb_datagram_iter
Date: Mon, 17 Jun 2024 09:58:52 -0700 [thread overview]
Message-ID: <20240617095852.66c96be9@kernel.org> (raw)
In-Reply-To: <033294ee-e6e6-4dca-b60c-019cb72a6857@grimberg.me>
On Mon, 17 Jun 2024 09:29:53 +0300 Sagi Grimberg wrote:
> > Probably because kmap() returns page_address() for non-highmem pages
> > while kmap_local_page() actually returns a kmap address:
> >
> > if (!IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP) && !PageHighMem(page))
> > return page_address(page);
> > return __kmap_local_pfn_prot(page_to_pfn(page), prot);
> >
> > so if skb frags are always lowmem (are they?) this is a false positive.
>
> AFAIR these buffers are coming from the RX ring, so they should be
> coming from a page_frag_cache,
> so I want to say always low memory?
>
> > if they can be highmem, then you've uncovered a bug that nobody's
> > noticed because nobody's testing on 32-bit any more.
>
> Not sure, Jakub? Eric?
My uneducated guess would be that until recent(ish) sendpage rework
from David Howells all high mem pages would have been single pages.
next prev parent reply other threads:[~2024-06-17 16:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 11:35 [PATCH] net: micro-optimize skb_datagram_iter Sagi Grimberg
2024-06-15 2:40 ` patchwork-bot+netdevbpf
2024-06-16 8:06 ` kernel test robot
2024-06-16 9:24 ` Sagi Grimberg
2024-06-16 21:51 ` David Laight
2024-06-16 21:53 ` Matthew Wilcox
2024-06-17 10:18 ` David Laight
2024-06-16 21:56 ` Matthew Wilcox
2024-06-17 6:29 ` Sagi Grimberg
2024-06-17 16:58 ` Jakub Kicinski [this message]
2024-06-18 6:37 ` Sagi Grimberg
2024-06-19 12:46 ` David Howells
2024-06-19 13:54 ` Sagi Grimberg
2024-06-19 14:51 ` Eric Dumazet
2024-06-19 14:56 ` Eric Dumazet
2024-06-19 15:25 ` Sagi Grimberg
2024-06-21 7:54 ` David Howells
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=20240617095852.66c96be9@kernel.org \
--to=kuba@kernel.org \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=lkp@intel.com \
--cc=netdev@vger.kernel.org \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=sagi@grimberg.me \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).