From: Baoquan He <bhe@redhat.com>
To: "HAGIO KAZUHITO(萩尾 一仁)" <k-hagio-ab@nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Dong Aisheng <dongas86@gmail.com>,
Dong Aisheng <aisheng.dong@nxp.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH V2 4/6] mm: rename the global section array to mem_sections
Date: Wed, 2 Jun 2021 11:03:53 +0800 [thread overview]
Message-ID: <20210602030353.GA409140@MiWiFi-R3L-srv> (raw)
In-Reply-To: <TYYPR01MB67775E2EC60DEE1195A49577DD3D9@TYYPR01MB6777.jpnprd01.prod.outlook.com>
On 06/02/21 at 01:11am, HAGIO KAZUHITO(萩尾 一仁) wrote:
> -----Original Message-----
> > On Tue, 1 Jun 2021 10:40:09 +0200 David Hildenbrand <david@redhat.com> wrote:
> >
> > > > Thanks, i explained the reason during my last reply.
> > > > Andrew has already picked this patch to -mm tree.
> > >
> > > Just because it's in Andrews tree doesn't mean it will end up upstream. ;)
> > >
> > > Anyhow, no really strong opinion, it's simply unnecessary code churn
> > > that makes bisecting harder without real value IMHO.
> >
> > I think it's a good change - mem_sections refers to multiple instances
> > of a mem_section. Churn is a pain, but that's the price we pay for more
> > readable code. And for having screwed it up originally ;)
>
> From a makedumpfile/crash-utility viewpoint, I don't deny kernel improvement
> and probably the change will not be hard for them to support, but I'd like
> you to remember that the tool users will need to update them for the change.
As VIM user, I can understand Aisheng's feeling on the mem_section
variable which has the same symbol name as its type. Meanwhile it does
cause makedumpfile/crash having to be changed accordingly.
Maybe we can carry it when any essential change is needed in both kernel
and makedumpfile/crash around it.
>
> The situation where we need to update the tools for new kernels is usual, but
> there are not many cases that they cannot even start session, and this change
By the way, Kazu, about a case starting session, could you be more specific
or rephrase? I may not get it clearly. Thanks.
> will cause it. Personally I wonder the change is worth forcing users to update
> them.
>
> Thanks,
> Kazu
>
_______________________________________________
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: "HAGIO KAZUHITO(萩尾 一仁)" <k-hagio-ab@nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Dong Aisheng <dongas86@gmail.com>,
Dong Aisheng <aisheng.dong@nxp.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH V2 4/6] mm: rename the global section array to mem_sections
Date: Wed, 2 Jun 2021 11:03:53 +0800 [thread overview]
Message-ID: <20210602030353.GA409140@MiWiFi-R3L-srv> (raw)
In-Reply-To: <TYYPR01MB67775E2EC60DEE1195A49577DD3D9@TYYPR01MB6777.jpnprd01.prod.outlook.com>
On 06/02/21 at 01:11am, HAGIO KAZUHITO(萩尾 一仁) wrote:
> -----Original Message-----
> > On Tue, 1 Jun 2021 10:40:09 +0200 David Hildenbrand <david@redhat.com> wrote:
> >
> > > > Thanks, i explained the reason during my last reply.
> > > > Andrew has already picked this patch to -mm tree.
> > >
> > > Just because it's in Andrews tree doesn't mean it will end up upstream. ;)
> > >
> > > Anyhow, no really strong opinion, it's simply unnecessary code churn
> > > that makes bisecting harder without real value IMHO.
> >
> > I think it's a good change - mem_sections refers to multiple instances
> > of a mem_section. Churn is a pain, but that's the price we pay for more
> > readable code. And for having screwed it up originally ;)
>
> From a makedumpfile/crash-utility viewpoint, I don't deny kernel improvement
> and probably the change will not be hard for them to support, but I'd like
> you to remember that the tool users will need to update them for the change.
As VIM user, I can understand Aisheng's feeling on the mem_section
variable which has the same symbol name as its type. Meanwhile it does
cause makedumpfile/crash having to be changed accordingly.
Maybe we can carry it when any essential change is needed in both kernel
and makedumpfile/crash around it.
>
> The situation where we need to update the tools for new kernels is usual, but
> there are not many cases that they cannot even start session, and this change
By the way, Kazu, about a case starting session, could you be more specific
or rephrase? I may not get it clearly. Thanks.
> will cause it. Personally I wonder the change is worth forcing users to update
> them.
>
> Thanks,
> Kazu
>
next prev parent reply other threads:[~2021-06-02 3:04 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-31 9:19 [PATCH V2 0/6] mm/sparse: a few minor fixes and improvements Dong Aisheng
2021-05-31 9:19 ` [PATCH V2 1/6] mm: drop SECTION_SHIFT in code comments Dong Aisheng
2021-05-31 18:08 ` Yu Zhao
2021-05-31 9:19 ` [PATCH V2 2/6] mm/sparse: free section usage memory in case populate_section_memmap failed Dong Aisheng
2021-05-31 15:06 ` Liam Howlett
2021-06-01 2:37 ` Dong Aisheng
2021-06-01 8:19 ` David Hildenbrand
2021-05-31 9:19 ` [PATCH V2 3/6] mm/sparse: move mem_sections allocation out of memory_present() Dong Aisheng
2021-05-31 14:39 ` Liam Howlett
2021-06-01 2:38 ` Dong Aisheng
2021-06-01 8:22 ` David Hildenbrand
2021-05-31 9:19 ` [PATCH V2 4/6] mm: rename the global section array to mem_sections Dong Aisheng
2021-05-31 9:19 ` Dong Aisheng
2021-06-01 8:22 ` David Hildenbrand
2021-06-01 8:22 ` David Hildenbrand
2021-06-01 8:37 ` Dong Aisheng
2021-06-01 8:37 ` Dong Aisheng
2021-06-01 8:40 ` David Hildenbrand
2021-06-01 8:40 ` David Hildenbrand
2021-06-01 8:44 ` Dong Aisheng
2021-06-01 8:44 ` Dong Aisheng
2021-06-01 23:52 ` Andrew Morton
2021-06-01 23:52 ` Andrew Morton
2021-06-02 1:11 ` HAGIO KAZUHITO(萩尾 一仁)
2021-06-02 1:11 ` HAGIO KAZUHITO(萩尾 一仁)
2021-06-02 2:26 ` Andrew Morton
2021-06-02 2:26 ` Andrew Morton
2021-06-02 3:03 ` Baoquan He [this message]
2021-06-02 3:03 ` Baoquan He
2021-06-02 5:02 ` HAGIO KAZUHITO(萩尾 一仁)
2021-06-02 5:02 ` HAGIO KAZUHITO(萩尾 一仁)
2021-06-02 5:22 ` Baoquan He
2021-06-02 5:22 ` Baoquan He
2021-05-31 9:19 ` [PATCH V2 5/6] mm/page_alloc: improve memmap_pages dbg msg Dong Aisheng
2021-06-01 8:23 ` David Hildenbrand
2021-05-31 9:19 ` [PATCH V2 6/6] mm/sparse: remove one duplicated #ifdef CONFIG_SPARSEMEM_EXTREME Dong Aisheng
2021-06-01 8:26 ` David Hildenbrand
2021-06-01 8:39 ` Dong Aisheng
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=20210602030353.GA409140@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=aisheng.dong@nxp.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=dongas86@gmail.com \
--cc=dyoung@redhat.com \
--cc=k-hagio-ab@nec.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vgoyal@redhat.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.