All of lore.kernel.org
 help / color / mirror / Atom feed
From: Byungchul Park <byungchul@sk.com>
To: Nadav Amit <namit@vmware.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	"kernel_team@skhynix.com" <kernel_team@skhynix.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"ying.huang@intel.com" <ying.huang@intel.com>,
	"xhao@linux.alibaba.com" <xhao@linux.alibaba.com>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
	"hughd@google.com" <hughd@google.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"david@redhat.com" <david@redhat.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [v3 2/3] mm: Defer TLB flush by keeping both src and dst folios at migration
Date: Tue, 31 Oct 2023 07:40:37 +0900	[thread overview]
Message-ID: <20231030224037.GA900@system.software.com> (raw)
In-Reply-To: <0138328C-74D5-471E-A2CC-7675CA692F42@vmware.com>

On Mon, Oct 30, 2023 at 03:58:44PM +0000, Nadav Amit wrote:
> 
> 
> > On Oct 30, 2023, at 2:51 PM, Byungchul Park <byungchul@sk.com> wrote:
> > 
> > I really spent a lot of time hesitating whether splitting it or not.
> > However, the test result cannot be stable without those. I'm still
> > confused. I think the test result should be stable at each commit,
> > right?
> 
> Of course. You can extract the optimization we mentioned, and perhaps
> have more preparatory patches.
> 
> Just a couple of comments that may also help breaking the patches:
> 
> 1. The “stopping” logic is a bit not great. Try to see if you can
> somehow use shrinker or OOM infrastructure instead.

The stopping means "temporarily pausing" expanding migrc's pending
queue, not shrinking folios.. Yeah my fault. I will rename it another
not to make guys get it wrong.

> 2. Regarding “overflows”, it’s not always a question of whether an
> overflow would happen naturally, but whether a malicious process can
> trigger it.

I understand what you are worried about. However, it's intended that
the variable is going to overflow. And the overflow doesn't matter if we
are aware of it and careful in handling it. See time_after() in
include/linux/jiffies.h. That would help you understand what I mean.

	Byungchul
> 
> Regards,
> Nadav
> 


  reply	other threads:[~2023-10-30 22:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30  7:25 [v3 0/3] Reduce TLB flushes under some specific conditions Byungchul Park
2023-10-30  7:25 ` [v3 1/3] mm/rmap: Recognize non-writable TLB entries during TLB batch flush Byungchul Park
2023-10-30  7:52   ` Nadav Amit
2023-10-30 10:26     ` Byungchul Park
2023-10-30  7:25 ` [v3 2/3] mm: Defer TLB flush by keeping both src and dst folios at migration Byungchul Park
2023-10-30  8:00   ` David Hildenbrand
2023-10-30  9:58     ` Byungchul Park
2023-11-01  3:06       ` Huang, Ying
2023-10-30  8:50   ` Nadav Amit
2023-10-30 12:51     ` Byungchul Park
2023-10-30 15:58       ` Nadav Amit
2023-10-30 22:40         ` Byungchul Park [this message]
2023-11-08  4:12       ` Byungchul Park
2023-11-09 10:16         ` Nadav Amit
2023-11-10  1:02           ` Byungchul Park
2023-11-10  3:13             ` Byungchul Park
2023-11-10 22:18               ` Nadav Amit
2023-11-15  5:48                 ` Byungchul Park
2023-11-09  5:35       ` Byungchul Park
2023-10-30  7:25 ` [v3 3/3] mm, migrc: Add a sysctl knob to enable/disable MIGRC mechanism Byungchul Park
2023-10-30  8:51   ` Nadav Amit
2023-10-30 10:36     ` Byungchul Park
2023-10-30 17:55 ` [v3 0/3] Reduce TLB flushes under some specific conditions Dave Hansen
2023-10-30 18:32   ` Nadav Amit
2023-10-30 22:55   ` Byungchul Park
2023-10-31  8:46     ` David Hildenbrand
2023-10-31  2:37   ` Byungchul Park

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=20231030224037.GA900@system.software.com \
    --to=byungchul@sk.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kernel_team@skhynix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=namit@vmware.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --cc=xhao@linux.alibaba.com \
    --cc=ying.huang@intel.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 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.