From: Borislav Petkov <bp@alien8.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Singh, Brijesh" <brijesh.singh@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
"H . Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>
Subject: Re: [PATCH] x86: mm: Do not use set_{pud,pmd}_safe when splitting the large page
Date: Tue, 9 Apr 2019 12:20:23 +0200 [thread overview]
Message-ID: <20190409102023.GA6150@zn.tnic> (raw)
In-Reply-To: <20190409093935.GH14281@hirez.programming.kicks-ass.net>
On Tue, Apr 09, 2019 at 11:39:35AM +0200, Peter Zijlstra wrote:
> unsigned long kernel_physical_mapping_change(unsigned long paddr_start, unsigned
> long paddr_end, unsigned long page_size_mask)
... and add a comment above it what the "_change" thing is supposed to
mean...
> unsigned long last;
>
> last = __kernel_physical_mapping_init(paddr_start, paddr_end, page_size_mask, false);
>
> __flush_tlb_all();
... and maybe not do the flushing here because if you look at
early_set_memory_enc_dec(), it iterates over a bunch of addresses and
when it is done, does the TLB flush once.
If you did it here, then you'd flush after each change. Which is costly.
So maybe the comment above should also say that _change callers are
responsible to flush the TLB after they're done.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2019-04-09 10:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 19:11 [PATCH] x86: mm: Do not use set_{pud,pmd}_safe when splitting the large page Singh, Brijesh
2019-04-09 8:40 ` Peter Zijlstra
2019-04-09 9:39 ` Peter Zijlstra
2019-04-09 10:20 ` Borislav Petkov [this message]
2019-04-09 19:09 ` Singh, Brijesh
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=20190409102023.GA6150@zn.tnic \
--to=bp@alien8.de \
--cc=Thomas.Lendacky@amd.com \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox