From: Baoquan He <bhe@redhat.com>
To: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Ard Biesheuvel <ardb@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Eric Biederman <ebiederm@xmission.com>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org, Dave Young <dyoung@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
Feng Zhou <zhoufeng.zf@bytedance.com>,
Chen Zhou <dingguo.cz@antgroup.com>,
John Donnelly <John.p.donnelly@oracle.com>,
Dave Kleikamp <dave.kleikamp@oracle.com>,
liushixin <liushixin2@huawei.com>
Subject: Re: [PATCH 5/5] arm64: kdump: Don't defer the reservation of crash high memory
Date: Mon, 27 Jun 2022 18:17:07 +0800 [thread overview]
Message-ID: <YrmDo7Sx1jNQ4WFd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <e3318551-4134-245a-c060-86ab81eb3e68@huawei.com>
On 06/27/22 at 05:17pm, Leizhen (ThunderTown) wrote:
>
>
> On 2022/6/27 10:52, Baoquan He wrote:
> > On 06/23/22 at 03:07pm, Catalin Marinas wrote:
> >> On Wed, Jun 22, 2022 at 04:35:16PM +0800, Baoquan He wrote:
> >>> On 06/21/22 at 07:04pm, Catalin Marinas wrote:
> >>>> The problem with splitting is that you can end up with two entries in
> >>>> the TLB for the same VA->PA mapping (e.g. one for a 4KB page and another
> >>>> for a 2MB block). In the lucky case, the CPU will trigger a TLB conflict
> >>>> abort (but can be worse like loss of coherency).
> >>>
> >>> Thanks for this explanation. Is this a drawback of arm64 design? X86
> >>> code do the same thing w/o issue, is there way to overcome this on
> >>> arm64 from hardware or software side?
> >>
> >> It is a drawback of the arm64 implementations. Having multiple TLB
> >> entries for the same VA would need additional logic in hardware to
> >> detect, so the microarchitects have pushed back. In ARMv8.4, some
> >> balanced was reached with FEAT_BBM so that the only visible side-effect
> >> is a potential TLB conflict abort that could be resolved by software.
> >
> > I see, thx.
> >
> >>
> >>> I ever got a arm64 server with huge memory, w or w/o crashkernel setting
> >>> have different bootup time. And the more often TLB miss and flush will
> >>> cause performance cost. It is really a pity if we have very powerful
> >>> arm64 cpu and system capacity, but bottlenecked by this drawback.
> >>
> >> Is it only the boot time affected or the runtime performance as well?
> >
> > Sorry for late reply. What I observerd is the boot time serious latecy
> > with huge memory. Since the timestamp is not available at that time,
> > we can't tell the number. I didn't notice the runtime performance.
>
> There's some data here, and I see you're not on the cc list.
>
> https://lore.kernel.org/linux-mm/1656241815-28494-1-git-send-email-guanghuifeng@linux.alibaba.com/T/
Thanks, Zhen Lei. I also saw the patch. That seems to be a good way,
since there's only one process running at that time. Not sure if there's
still risk of multiple TLB entries for the same VA existing.
next prev parent reply other threads:[~2022-06-27 10:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 8:09 [PATCH 0/5] arm64: kdump: Function supplement and performance optimization Zhen Lei
2022-06-13 8:09 ` [PATCH 1/5] arm64: kdump: Provide default size when crashkernel=Y,low is not specified Zhen Lei
2022-06-17 2:40 ` Baoquan He
2022-06-17 7:39 ` Leizhen (ThunderTown)
2022-06-17 8:26 ` Baoquan He
2022-06-13 8:09 ` [PATCH 2/5] arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones Zhen Lei
2022-06-17 4:16 ` Baoquan He
2022-06-13 8:09 ` [PATCH 3/5] arm64: kdump: Remove some redundant checks in map_mem() Zhen Lei
2022-06-20 7:42 ` Baoquan He
2022-06-13 8:09 ` [PATCH 4/5] arm64: kdump: Decide when to reserve crash memory in reserve_crashkernel() Zhen Lei
2022-06-13 8:09 ` [PATCH 5/5] arm64: kdump: Don't defer the reservation of crash high memory Zhen Lei
2022-06-21 5:33 ` Baoquan He
2022-06-21 6:24 ` Kefeng Wang
2022-06-21 9:27 ` Baoquan He
2022-06-21 18:04 ` Catalin Marinas
2022-06-22 8:35 ` Baoquan He
2022-06-23 14:07 ` Catalin Marinas
2022-06-27 2:52 ` Baoquan He
2022-06-27 9:17 ` Leizhen (ThunderTown)
2022-06-27 10:17 ` Baoquan He [this message]
2022-06-27 11:11 ` Leizhen (ThunderTown)
2022-06-22 12:03 ` Kefeng Wang
2022-06-23 10:27 ` Catalin Marinas
2022-06-23 14:23 ` Kefeng Wang
2022-06-21 7:56 ` Leizhen (ThunderTown)
2022-06-21 9:35 ` Baoquan He
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=YrmDo7Sx1jNQ4WFd@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=John.p.donnelly@oracle.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dave.kleikamp@oracle.com \
--cc=devicetree@vger.kernel.org \
--cc=dingguo.cz@antgroup.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=frowand.list@gmail.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liushixin2@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
--cc=thunder.leizhen@huawei.com \
--cc=vgoyal@redhat.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=zhoufeng.zf@bytedance.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;
as well as URLs for NNTP newsgroup(s).