LKML Archive on
help / color / mirror / Atom feed
From: Matthew Wilcox <>
To: Eric Dumazet <>
Cc: Christoph Hellwig <>,
	Eric Dumazet <>,
	"David S . Miller" <>,
	netdev <>,
	Andy Lutomirski <>,
	linux-kernel <>,
	linux-mm <>,
	Soheil Hassas Yeganeh <>
Subject: Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
Date: Wed, 25 Apr 2018 09:30:14 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Apr 25, 2018 at 09:20:55AM -0700, Eric Dumazet wrote:
> 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.

Sorry, I was unclear.  zap_page_range() bulk-invalidates all pages that
were torn down as part of this call.  What I was trying to say was that
we could have a whole new API which put page after page into the same
address, and bumped the refcount on them to prevent them from actually
being freed.  Once we get to a batch limit, we invalidate all of the
pages which were mapped at those addresses and can then free the pages
back to the allocator.

I don't think you can implement this scheme on s390 because it requires
the userspace address to still be mapped to that page on shootdown
(?) but I think we could implement it on x86.

Another possibility is if we had some way to insert the TLB entry into
the local CPU's page tables only, we wouldn't need to broadcast-invalidate
the TLB entry; we could just do it locally which is relatively quick.

  reply	other threads:[~2018-04-25 16:30 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 " 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
2018-04-25 16:30           ` Matthew Wilcox [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).