All of lore.kernel.org
 help / color / mirror / Atom feed
From: "guanghui.fgh" <guanghuifeng@linux.alibaba.com>
To: Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>
Cc: baolin.wang@linux.alibaba.com, catalin.marinas@arm.com,
	akpm@linux-foundation.org, david@redhat.com, jianyong.wu@arm.com,
	james.morse@arm.com, quic_qiancai@quicinc.com,
	christophe.leroy@csgroup.eu, jonathan@marek.ca,
	mark.rutland@arm.com, thunder.leizhen@huawei.com,
	anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, rppt@kernel.org,
	geert+renesas@glider.be, linux-mm@kvack.org,
	yaohongbo@linux.alibaba.com,
	alikernel-developer@linux.alibaba.com
Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation
Date: Tue, 5 Jul 2022 20:07:07 +0800	[thread overview]
Message-ID: <5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com> (raw)
In-Reply-To: <20220705095231.GB552@willie-the-truck>



在 2022/7/5 17:52, Will Deacon 写道:
> On Mon, Jul 04, 2022 at 07:09:23PM +0200, Ard Biesheuvel wrote:
>> On Mon, 4 Jul 2022 at 18:38, Will Deacon <will@kernel.org> wrote:
>>>
>>> On Mon, Jul 04, 2022 at 10:34:07PM +0800, guanghui.fgh wrote:
>>>> Thanks.
>>>>
>>>> 在 2022/7/4 22:23, Will Deacon 写道:
>>>>> On Mon, Jul 04, 2022 at 10:11:27PM +0800, guanghui.fgh wrote:
>> ...
>>>>>> Namely, it's need to use non block/section mapping for crashkernel mem
>>>>>> before shringking.
>>>>>
>>>>> Well, yes, but we can change arch_kexec_[un]protect_crashkres() not to do
>>>>> that if we're leaving the thing mapped, no?
>>>>>
>>>> I think we should use arch_kexec_[un]protect_crashkres for crashkernel mem.
>>>>
>>>> Because when invalid crashkernel mem pagetable, there is no chance to rd/wr
>>>> the crashkernel mem by mistake.
>>>>
>>>> If we don't use arch_kexec_[un]protect_crashkres to invalid crashkernel mem
>>>> pagetable, there maybe some write operations to these mem by mistake which
>>>> may cause crashkernel boot error and vmcore saving error.
>>>
>>> I don't really buy this line of reasoning. The entire main kernel is
>>> writable, so why do we care about protecting the crashkernel so much? The
>>> _code_ to launch the crash kernel is writable! If you care about preventing
>>> writes to memory which should not be writable, then you should use
>>> rodata=full.
>>>
>>
>> This is not entirely true - the core kernel text and rodata are
>> remapped r/o in the linear map, whereas all module code and rodata are
>> left writable when rodata != full.
> 
> Yes, sorry, you're quite right. The kernel text is only writable if
> rodata=off.
> 
> But I still think it makes sense to protect the crashkernel only if
> rodata=full (which is the default on arm64) as this allows us to rely
> on page mappings and I think fits well with what we do for modules.
> 
>> But the conclusion is the same, imo: if you can't be bothered to
>> protect a good chunk of the code and rodata that the kernel relies on,
>> why should the crashkernel be treated any differently?
> 
> Thanks.
> 
> Will
Thanks.

1.The rodata full is harm to the performance and has been disabled in-house.

2.When using crashkernel with rodata non full, the kernel also will use 
non block/section mapping which cause high d-TLB miss and degrade 
performance greatly.
This patch fix it to use block/section mapping as far as possible.

bool can_set_direct_map(void)
{
	return rodata_full || debug_pagealloc_enabled();
}

map_mem:
if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE))
	flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;

3.When rodata full is disabled, crashkernel also need protect(keep 
arch_kexec_[un]protect_crashkres using).
I think crashkernel should't depend on radata full(Maybe other 
architecture don't support radata full now).

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: "guanghui.fgh" <guanghuifeng@linux.alibaba.com>
To: Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>
Cc: baolin.wang@linux.alibaba.com, catalin.marinas@arm.com,
	akpm@linux-foundation.org, david@redhat.com, jianyong.wu@arm.com,
	james.morse@arm.com, quic_qiancai@quicinc.com,
	christophe.leroy@csgroup.eu, jonathan@marek.ca,
	mark.rutland@arm.com, thunder.leizhen@huawei.com,
	anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, rppt@kernel.org,
	geert+renesas@glider.be, linux-mm@kvack.org,
	yaohongbo@linux.alibaba.com,
	alikernel-developer@linux.alibaba.com
Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation
Date: Tue, 5 Jul 2022 20:07:07 +0800	[thread overview]
Message-ID: <5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com> (raw)
In-Reply-To: <20220705095231.GB552@willie-the-truck>



在 2022/7/5 17:52, Will Deacon 写道:
> On Mon, Jul 04, 2022 at 07:09:23PM +0200, Ard Biesheuvel wrote:
>> On Mon, 4 Jul 2022 at 18:38, Will Deacon <will@kernel.org> wrote:
>>>
>>> On Mon, Jul 04, 2022 at 10:34:07PM +0800, guanghui.fgh wrote:
>>>> Thanks.
>>>>
>>>> 在 2022/7/4 22:23, Will Deacon 写道:
>>>>> On Mon, Jul 04, 2022 at 10:11:27PM +0800, guanghui.fgh wrote:
>> ...
>>>>>> Namely, it's need to use non block/section mapping for crashkernel mem
>>>>>> before shringking.
>>>>>
>>>>> Well, yes, but we can change arch_kexec_[un]protect_crashkres() not to do
>>>>> that if we're leaving the thing mapped, no?
>>>>>
>>>> I think we should use arch_kexec_[un]protect_crashkres for crashkernel mem.
>>>>
>>>> Because when invalid crashkernel mem pagetable, there is no chance to rd/wr
>>>> the crashkernel mem by mistake.
>>>>
>>>> If we don't use arch_kexec_[un]protect_crashkres to invalid crashkernel mem
>>>> pagetable, there maybe some write operations to these mem by mistake which
>>>> may cause crashkernel boot error and vmcore saving error.
>>>
>>> I don't really buy this line of reasoning. The entire main kernel is
>>> writable, so why do we care about protecting the crashkernel so much? The
>>> _code_ to launch the crash kernel is writable! If you care about preventing
>>> writes to memory which should not be writable, then you should use
>>> rodata=full.
>>>
>>
>> This is not entirely true - the core kernel text and rodata are
>> remapped r/o in the linear map, whereas all module code and rodata are
>> left writable when rodata != full.
> 
> Yes, sorry, you're quite right. The kernel text is only writable if
> rodata=off.
> 
> But I still think it makes sense to protect the crashkernel only if
> rodata=full (which is the default on arm64) as this allows us to rely
> on page mappings and I think fits well with what we do for modules.
> 
>> But the conclusion is the same, imo: if you can't be bothered to
>> protect a good chunk of the code and rodata that the kernel relies on,
>> why should the crashkernel be treated any differently?
> 
> Thanks.
> 
> Will
Thanks.

1.The rodata full is harm to the performance and has been disabled in-house.

2.When using crashkernel with rodata non full, the kernel also will use 
non block/section mapping which cause high d-TLB miss and degrade 
performance greatly.
This patch fix it to use block/section mapping as far as possible.

bool can_set_direct_map(void)
{
	return rodata_full || debug_pagealloc_enabled();
}

map_mem:
if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE))
	flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;

3.When rodata full is disabled, crashkernel also need protect(keep 
arch_kexec_[un]protect_crashkres using).
I think crashkernel should't depend on radata full(Maybe other 
architecture don't support radata full now).

Thanks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-05 12:14 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-02 15:57 [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation Guanghui Feng
2022-07-02 15:57 ` Guanghui Feng
2022-07-04 10:35 ` Will Deacon
2022-07-04 10:35   ` Will Deacon
2022-07-04 10:58   ` guanghui.fgh
2022-07-04 10:58     ` guanghui.fgh
2022-07-04 11:14     ` Will Deacon
2022-07-04 11:14       ` Will Deacon
2022-07-04 12:05       ` guanghui.fgh
2022-07-04 12:05         ` guanghui.fgh
2022-07-04 13:15         ` Will Deacon
2022-07-04 13:15           ` Will Deacon
2022-07-04 13:41           ` guanghui.fgh
2022-07-04 13:41             ` guanghui.fgh
2022-07-04 14:11           ` guanghui.fgh
2022-07-04 14:11             ` guanghui.fgh
2022-07-04 14:23             ` Will Deacon
2022-07-04 14:23               ` Will Deacon
2022-07-04 14:34               ` guanghui.fgh
2022-07-04 14:34                 ` guanghui.fgh
2022-07-04 16:38                 ` Will Deacon
2022-07-04 16:38                   ` Will Deacon
2022-07-04 17:09                   ` Ard Biesheuvel
2022-07-04 17:09                     ` Ard Biesheuvel
2022-07-05  8:35                     ` Baoquan He
2022-07-05  8:35                       ` Baoquan He
2022-07-05  8:35                       ` Baoquan He
2022-07-05  9:52                     ` Will Deacon
2022-07-05  9:52                       ` Will Deacon
2022-07-05 12:07                       ` guanghui.fgh [this message]
2022-07-05 12:07                         ` guanghui.fgh
2022-07-05 12:11                         ` Will Deacon
2022-07-05 12:11                           ` Will Deacon
2022-07-05 12:27                           ` guanghui.fgh
2022-07-05 12:27                             ` guanghui.fgh
2022-07-05 12:56                           ` Mike Rapoport
2022-07-05 12:56                             ` Mike Rapoport
2022-07-05 13:17                             ` guanghui.fgh
2022-07-05 13:17                               ` guanghui.fgh
2022-07-05 15:02                           ` Mike Rapoport
2022-07-05 15:02                             ` Mike Rapoport
2022-07-05 15:34                             ` Catalin Marinas
2022-07-05 15:34                               ` Catalin Marinas
2022-07-05 15:57                               ` Mike Rapoport
2022-07-05 15:57                                 ` Mike Rapoport
2022-07-05 17:05                                 ` Catalin Marinas
2022-07-05 17:05                                   ` Catalin Marinas
2022-07-05 20:45                                   ` Mike Rapoport
2022-07-05 20:45                                     ` Mike Rapoport
2022-07-06  2:49                                     ` guanghui.fgh
2022-07-06  2:49                                       ` guanghui.fgh
2022-07-06  7:43                                       ` Catalin Marinas
2022-07-06  7:43                                         ` Catalin Marinas
2022-07-06 10:04                                     ` Catalin Marinas
2022-07-06 10:04                                       ` Catalin Marinas
2022-07-06 13:54                                       ` Mike Rapoport
2022-07-06 13:54                                         ` Mike Rapoport
2022-07-06 15:18                                         ` guanghui.fgh
2022-07-06 15:18                                           ` guanghui.fgh
2022-07-06 15:30                                           ` guanghui.fgh
2022-07-06 15:30                                             ` guanghui.fgh
2022-07-06 15:40                                           ` Catalin Marinas
2022-07-06 15:40                                             ` Catalin Marinas
2022-07-07 17:02                                             ` guanghui.fgh
2022-07-07 17:02                                               ` guanghui.fgh
2022-07-08 12:28                                             ` [PATCH RESEND " guanghui.fgh
2022-07-08 12:28                                               ` guanghui.fgh
2022-07-10 13:44                                               ` [PATCH v5] " Guanghui Feng
2022-07-10 13:44                                                 ` Guanghui Feng
2022-07-10 14:32                                                 ` guanghui.fgh
2022-07-10 14:32                                                   ` guanghui.fgh
2022-07-10 15:33                                                 ` guanghui.fgh
2022-07-10 15:33                                                   ` guanghui.fgh
2022-07-18 13:10                                                   ` Will Deacon
2022-07-18 13:10                                                     ` Will Deacon
2022-07-25  6:46                                                     ` Mike Rapoport
2022-07-25  6:46                                                       ` Mike Rapoport
2022-07-05  2:44                   ` [PATCH v4] " guanghui.fgh
2022-07-05  2:44                     ` guanghui.fgh

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=5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com \
    --to=guanghuifeng@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=alikernel-developer@linux.alibaba.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=david@redhat.com \
    --cc=geert+renesas@glider.be \
    --cc=james.morse@arm.com \
    --cc=jianyong.wu@arm.com \
    --cc=jonathan@marek.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=quic_qiancai@quicinc.com \
    --cc=rppt@kernel.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=will@kernel.org \
    --cc=yaohongbo@linux.alibaba.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.