From: Eric Dumazet <eric.dumazet@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Soheil Hassas Yeganeh <soheil@google.com>
Subject: Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
Date: Wed, 25 Apr 2018 09:20:55 -0700 [thread overview]
Message-ID: <8ce78bd6-8142-2937-11fd-2e4a2b22d90c@gmail.com> (raw)
In-Reply-To: <20180425160413.GC8546@bombadil.infradead.org>
On 04/25/2018 09:04 AM, Matthew Wilcox wrote:
> If you don't zap the page range, any of the CPUs in the system where
> any thread in this task have ever run may have a TLB entry pointing to
> this page ... if the page is being recycled into the page allocator,
> then that page might end up as a slab page or page table or page cache
> while the other CPU still have access to it.
Yes, this makes sense.
>
> You could hang onto the page until you've built up a sufficiently large
> batch, then bulk-invalidate all of the TLB entries, but we start to get
> into weirdnesses on different CPU architectures.
>
zap_page_range() is already doing a bulk-invalidate,
so maybe vm_replace_page() wont bring serious improvement if we end-up doing same dance.
Thanks.
next prev parent reply other threads:[~2018-04-25 16:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 5:27 [PATCH net-next 0/2] tcp: mmap: rework zerocopy receive Eric Dumazet
2018-04-25 5:27 ` [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for " Eric Dumazet
2018-04-25 6:28 ` Christoph Hellwig
2018-04-25 13:01 ` Eric Dumazet
2018-04-25 15:24 ` Christoph Hellwig
2018-04-25 16:04 ` Matthew Wilcox
2018-04-25 16:20 ` Eric Dumazet [this message]
2018-04-25 16:30 ` Matthew Wilcox
2018-04-25 16:22 ` Andy Lutomirski
2018-04-25 16:35 ` Eric Dumazet
2018-04-25 16:44 ` Eric Dumazet
2018-04-25 13:42 ` Eric Dumazet
2018-04-25 5:27 ` [PATCH net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE Eric Dumazet
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=8ce78bd6-8142-2937-11fd-2e4a2b22d90c@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=soheil@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.