All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Yuntao Wang <ytcoode@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	bp@alien8.de, dave.hansen@linux.intel.com, dyoung@redhat.com,
	eric.devolder@oracle.com, hbathini@linux.ibm.com, hpa@zytor.com,
	kexec@lists.infradead.org, lijiang@redhat.com,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	seanjc@google.com, sourabhjain@linux.ibm.com, tglx@linutronix.de,
	tiwai@suse.de, vgoyal@redhat.com, x86@kernel.org
Subject: Re: [PATCH 3/3] crash_core: fix and simplify the logic of crash_exclude_mem_range()
Date: Tue, 2 Jan 2024 16:41:17 +0800	[thread overview]
Message-ID: <ZZPMLextp0n3lwbD@MiWiFi-R3L-srv> (raw)
In-Reply-To: <ZY/uBJmpG14Ogvet@MiWiFi-R3L-srv>

Hi Yuntao,

On 12/30/23 at 06:16pm, Baoquan He wrote:
> On 12/29/23 at 12:10pm, Andrew Morton wrote:
> > On Sat, 16 Dec 2023 11:31:04 +0800 Baoquan He <bhe@redhat.com> wrote:
> > 
> > > > > Imagine we have a crashkernel region 256M reserved under 4G, say [2G, 2G+256M].
> > > > > Then after excluding the 256M from a region, it should stop. But now, this patch
> > > > > will make it continue scanning. Not sure if it's all in my mind.
> > > > 
> > > > Hi Baoquan,
> > > > 
> > > > Thank you for such a detailed reply. Now I finally understand why the code is
> > > > written this way.
> > > > 
> > > > However, if we can guarantee its correctness, wouldn't it be better to use the
> > > > generic region removing logic? At least it is more concise and clear, and other
> > > > people reading this code for the first time wouldn't get confused like me.
> > > > 
> > > > As for your concern about the while loop, I think it wouldn't affect performance
> > > > much because the total number of loops is small.
> > > 
> > > Well, see below kexec-tools commit, you wouldn't say that. And when you
> > > understand the code, you will feel a little uncomfortable about the
> > > sustaining useless scanning. At least, we should stop scanning after
> > > needed exluding is done.
> > > 
> > > Or, we may need add a generic region removing function so that it
> > > can be shared, e.g e820 memory region removing, memblock region removing.
> > > Otherwise, I can't see why a specific region excluding need a generic 
> > > region removing function.
> > 
> > So where do we now stand on this patchset?
> 
> The patch 1 and 2 are good clean up. The patch 3 plus below one, the
> entire is a good code improvement patch.
> 
> [PATCH] crash_core: optimize crash_exclude_mem_range()
> https://lore.kernel.org/all/20231219163418.108591-1-ytcoode@gmail.com/T/#u

Can you repost this patchset with some updating, e.g adding ack in patch
1 and 2, and squash below patch into patch 3? This will be easier for
patch merging.

[PATCH] crash_core: optimize crash_exclude_mem_range()
https://lore.kernel.org/all/20231219163418.108591-1-ytcoode@gmail.com/T/#u

And, you may need to drop below patchset since patch 2 conflicts with
this patchset, and patch 1 is conflicting with fuqiang's patch.

[PATCH 0/2] crash: fix potential cmem->ranges array overflow

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Yuntao Wang <ytcoode@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	bp@alien8.de, dave.hansen@linux.intel.com, dyoung@redhat.com,
	eric.devolder@oracle.com, hbathini@linux.ibm.com, hpa@zytor.com,
	kexec@lists.infradead.org, lijiang@redhat.com,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	seanjc@google.com, sourabhjain@linux.ibm.com, tglx@linutronix.de,
	tiwai@suse.de, vgoyal@redhat.com, x86@kernel.org
Subject: Re: [PATCH 3/3] crash_core: fix and simplify the logic of crash_exclude_mem_range()
Date: Tue, 2 Jan 2024 16:41:17 +0800	[thread overview]
Message-ID: <ZZPMLextp0n3lwbD@MiWiFi-R3L-srv> (raw)
In-Reply-To: <ZY/uBJmpG14Ogvet@MiWiFi-R3L-srv>

Hi Yuntao,

On 12/30/23 at 06:16pm, Baoquan He wrote:
> On 12/29/23 at 12:10pm, Andrew Morton wrote:
> > On Sat, 16 Dec 2023 11:31:04 +0800 Baoquan He <bhe@redhat.com> wrote:
> > 
> > > > > Imagine we have a crashkernel region 256M reserved under 4G, say [2G, 2G+256M].
> > > > > Then after excluding the 256M from a region, it should stop. But now, this patch
> > > > > will make it continue scanning. Not sure if it's all in my mind.
> > > > 
> > > > Hi Baoquan,
> > > > 
> > > > Thank you for such a detailed reply. Now I finally understand why the code is
> > > > written this way.
> > > > 
> > > > However, if we can guarantee its correctness, wouldn't it be better to use the
> > > > generic region removing logic? At least it is more concise and clear, and other
> > > > people reading this code for the first time wouldn't get confused like me.
> > > > 
> > > > As for your concern about the while loop, I think it wouldn't affect performance
> > > > much because the total number of loops is small.
> > > 
> > > Well, see below kexec-tools commit, you wouldn't say that. And when you
> > > understand the code, you will feel a little uncomfortable about the
> > > sustaining useless scanning. At least, we should stop scanning after
> > > needed exluding is done.
> > > 
> > > Or, we may need add a generic region removing function so that it
> > > can be shared, e.g e820 memory region removing, memblock region removing.
> > > Otherwise, I can't see why a specific region excluding need a generic 
> > > region removing function.
> > 
> > So where do we now stand on this patchset?
> 
> The patch 1 and 2 are good clean up. The patch 3 plus below one, the
> entire is a good code improvement patch.
> 
> [PATCH] crash_core: optimize crash_exclude_mem_range()
> https://lore.kernel.org/all/20231219163418.108591-1-ytcoode@gmail.com/T/#u

Can you repost this patchset with some updating, e.g adding ack in patch
1 and 2, and squash below patch into patch 3? This will be easier for
patch merging.

[PATCH] crash_core: optimize crash_exclude_mem_range()
https://lore.kernel.org/all/20231219163418.108591-1-ytcoode@gmail.com/T/#u

And, you may need to drop below patchset since patch 2 conflicts with
this patchset, and patch 1 is conflicting with fuqiang's patch.

[PATCH 0/2] crash: fix potential cmem->ranges array overflow

Thanks
Baoquan


  reply	other threads:[~2024-01-02  8:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 16:38 [PATCH 0/3] Some cleanups and fixes Yuntao Wang
2023-12-14 16:38 ` Yuntao Wang
2023-12-14 16:38 ` [PATCH 1/3] x86/crash: remove the unused image parameter from prepare_elf_headers() Yuntao Wang
2023-12-14 16:38   ` Yuntao Wang
2023-12-15  3:27   ` Baoquan He
2023-12-15  3:27     ` Baoquan He
2023-12-14 16:38 ` [PATCH 2/3] x86/crash: use SZ_1M macro instead of hardcoded value Yuntao Wang
2023-12-14 16:38   ` Yuntao Wang
2023-12-15  3:28   ` Baoquan He
2023-12-15  3:28     ` Baoquan He
2023-12-14 16:38 ` [PATCH 3/3] crash_core: fix and simplify the logic of crash_exclude_mem_range() Yuntao Wang
2023-12-14 16:38   ` Yuntao Wang
2023-12-15 15:15   ` Baoquan He
2023-12-15 15:15     ` Baoquan He
2023-12-16  1:54     ` Yuntao Wang
2023-12-16  1:54       ` Yuntao Wang
2023-12-16  3:31       ` Baoquan He
2023-12-16  3:31         ` Baoquan He
2023-12-29 20:10         ` Andrew Morton
2023-12-29 20:10           ` Andrew Morton
2023-12-30 10:16           ` Baoquan He
2023-12-30 10:16             ` Baoquan He
2024-01-02  8:41             ` Baoquan He [this message]
2024-01-02  8:41               ` Baoquan He
2024-01-02 15:06               ` Yuntao Wang
2024-01-02 15:06                 ` Yuntao Wang

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=ZZPMLextp0n3lwbD@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dyoung@redhat.com \
    --cc=eric.devolder@oracle.com \
    --cc=hbathini@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=lijiang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=seanjc@google.com \
    --cc=sourabhjain@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.de \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --cc=ytcoode@gmail.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.