linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	Yin Fengwei <fengwei.yin@intel.com>,
	David Hildenbrand <david@redhat.com>, Yu Zhao <yuzhao@google.com>,
	Yang Shi <shy828301@gmail.com>,
	"Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v4 0/3] Optimize large folio interaction with deferred split
Date: Thu, 3 Aug 2023 13:48:49 +0100	[thread overview]
Message-ID: <2f3a4ab5-dea3-deaf-6f6d-01ac4a5716b2@arm.com> (raw)
In-Reply-To: <20230803120100.2glxdc4yf7sjn7h5@box.shutemov.name>

On 03/08/2023 13:01, Kirill A. Shutemov wrote:
> On Wed, Aug 02, 2023 at 05:42:23PM +0100, Ryan Roberts wrote:
>>  - avoid the split lock contention by using mmu gather (suggested by Kirill)
> 
> [Offlist]
> 
> So, my idea is to embed struct deferred_split into struct mmu_gather and
> make zap path to use it instead of per-node/per-memcg deferred_split. This
> would avoid lock contention. If the list is not empty after zap, move the
> to the per-node/per-memcg deferred_split.
> 
> But it is only relevant if we see lock contention.
> 

Thanks Kiryl, I understand the proposal now. Having thought about this over
night, I'm thinking I'll just implement the full batch approach that Yu
proposed. In this case, we will get the benefits of batching rmap removal (for
all folio types) and as a side benefit we will get the lock contention reduction
(if there is lock contention) without the need for the new per-mmu_gather struct
deferred_split. Shout if you have issue with this.


      reply	other threads:[~2023-08-03 12:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27 14:18 Ryan Roberts
2023-07-27 14:18 ` [PATCH v4 1/3] mm: Allow deferred splitting of arbitrary large anon folios Ryan Roberts
2023-07-27 14:18 ` [PATCH v4 2/3] mm: Implement folio_remove_rmap_range() Ryan Roberts
2023-07-27 14:18 ` [PATCH v4 3/3] mm: Batch-zap large anonymous folio PTE mappings Ryan Roberts
2023-07-27 17:22   ` Yu Zhao
2023-07-28  9:16     ` Ryan Roberts
2023-08-01  7:12       ` Yu Zhao
2023-08-03 13:57     ` David Hildenbrand
2023-08-03 13:38   ` David Hildenbrand
2023-08-03 13:50     ` David Hildenbrand
2023-08-03 13:56     ` Ryan Roberts
2023-08-03 14:10       ` David Hildenbrand
2023-08-03 14:15         ` Ryan Roberts
2023-08-03 14:21           ` David Hildenbrand
2023-08-03 14:28           ` Zi Yan
2023-08-02 16:42 ` [PATCH v4 0/3] Optimize large folio interaction with deferred split Ryan Roberts
2023-08-02 17:02   ` Yu Zhao
2023-08-03 12:01   ` Kirill A. Shutemov
2023-08-03 12:48     ` Ryan Roberts [this message]

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=2f3a4ab5-dea3-deaf-6f6d-01ac4a5716b2@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nathan@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=yuzhao@google.com \
    --cc=ziy@nvidia.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