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 1/3] mm/rmap: Recognize non-writable TLB entries during TLB batch flush
Date: Mon, 30 Oct 2023 19:26:31 +0900	[thread overview]
Message-ID: <20231030102631.GB81877@system.software.com> (raw)
In-Reply-To: <1DB097E6-6585-4D10-95C9-7BAA5A622B7E@vmware.com>

On Mon, Oct 30, 2023 at 07:52:05AM +0000, Nadav Amit wrote:
> 
> Below are some points you might find useful:

Thank you!

> > +
> > /*
> >  * Blindly accessing user memory from NMI context can be dangerous
> >  * if we're in the middle of switching the current user task or
> > diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
> > index aa44fff8bb9d..35ba9425d48d 100644
> > --- a/include/linux/mm_types_task.h
> > +++ b/include/linux/mm_types_task.h
> > @@ -59,8 +59,8 @@ struct tlbflush_unmap_batch {
> > 	 */
> > 	struct arch_tlbflush_unmap_batch arch;
> > 
> > -	/* True if a flush is needed. */
> > -	bool flush_required;
> > +	/* The number of flush requested. */
> 
> Number of what? Base pages I presume.

How many times set_tlb_ubc_flush_pending() has been called.

> > +	int nr_flush_required;
> 
> Perhaps unsigned would be better suited?

Will change it to unsigned.

> > 	/*
> > 	 * If true then the PTE was dirty when unmapped. The entry must be
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 77f01ac385f7..63189c023357 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1324,6 +1324,7 @@ struct task_struct {
> > #endif
> > 
> > 	struct tlbflush_unmap_batch	tlb_ubc;
> > +	struct tlbflush_unmap_batch	tlb_ubc_nowr;
> 
> tlb_ubc_nowr is - I think - less informative the tlb_ubc_ro (and a comment
> would be useful).

At the beginning, I named it tlb_ubc_ro but.. I forgot why I changed it
to tlb_ubc_nowr but.. I will change it back and add a comment on it.

> > +
> > +int nr_flush_required(void)
> > +{
> > +	return current->tlb_ubc.nr_flush_required;
> > +}
> > +
> > +int nr_flush_required_nowr(void)
> > +{
> > +	return current->tlb_ubc_nowr.nr_flush_required;
> > +}
> 
> I haven’t gone through the users of these functions yet, as they are not included
> in this patch (which is usually not great).

Right. I will place these two on another patch that uses the functions.
Or need to add an explanation in this commit message.

> Anyhow, it might be a bit wasteful to have a function call for such a function. See
> if it is possible to avoid that call.

I will move them to mm/internal.h with inline added if possible.

> > +
> > /*
> >  * Flush TLB entries for recently unmapped pages from remote CPUs. It is
> >  * important if a PTE was dirty when it was unmapped that it's flushed
> > @@ -615,11 +641,12 @@ void try_to_unmap_flush(void)
> > {
> > 	struct tlbflush_unmap_batch *tlb_ubc = &current->tlb_ubc;
> > 
> > -	if (!tlb_ubc->flush_required)
> > +	fold_ubc_nowr();
> > +	if (!tlb_ubc->nr_flush_required)
> > 		return;
> > 
> > 	arch_tlbbatch_flush(&tlb_ubc->arch);
> > -	tlb_ubc->flush_required = false;
> > +	tlb_ubc->nr_flush_required = 0;
> > 	tlb_ubc->writable = false;
> > }
> > 
> > @@ -627,8 +654,9 @@ void try_to_unmap_flush(void)
> > void try_to_unmap_flush_dirty(void)
> > {
> > 	struct tlbflush_unmap_batch *tlb_ubc = &current->tlb_ubc;
> > +	struct tlbflush_unmap_batch *tlb_ubc_nowr = &current->tlb_ubc_nowr;
> > 
> > -	if (tlb_ubc->writable)
> > +	if (tlb_ubc->writable || tlb_ubc_nowr->writable)
> > 		try_to_unmap_flush();
> > }
> > 
> > @@ -645,15 +673,16 @@ void try_to_unmap_flush_dirty(void)
> > static void set_tlb_ubc_flush_pending(struct mm_struct *mm, pte_t pteval,
> > 				      unsigned long uaddr)
> > {
> > -	struct tlbflush_unmap_batch *tlb_ubc = &current->tlb_ubc;
> > +	struct tlbflush_unmap_batch *tlb_ubc;
> > 	int batch;
> > 	bool writable = pte_dirty(pteval);
> > 
> > 	if (!pte_accessible(mm, pteval))
> > 		return;
> > 
> > +	tlb_ubc = pte_write(pteval) || writable ? &current->tlb_ubc : &current->tlb_ubc_nowr;
> 
> Using the ternary operator here is a bit confusing. You can use an “if”
> instead or if you mind is set doing it this way at least make it easier to
> read:
> 
> 	tlb_ubc = (pte_write(pteval) || writable) ? &current->tlb_ubc :
> 						    &current->tlb_ubc_nowr;

You are right. I should change it that way. Thanks.

> And of course, add a comment.

Okay. Also will add a comment.

> > 	arch_tlbbatch_add_pending(&tlb_ubc->arch, mm, uaddr);
> > -	tlb_ubc->flush_required = true;
> > +	tlb_ubc->nr_flush_required += 1;
> 
> Presumably overflow is impossible for other reasons, but something like that
> worries me.

Agree with you. Lemme think it more and fix it.

Thank you.

	Byungchul



  reply	other threads:[~2023-10-30 10:26 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 [this message]
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
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=20231030102631.GB81877@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.