From: Luiz Capitulino <lcapitulino@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
riel@redhat.com, andi@firstfloor.org, akpm@linux-foundation.org
Subject: Re: [PATCH] x86: numa: setup_node_data(): drop dead code and rename function
Date: Wed, 2 Jul 2014 23:39:01 -0400 [thread overview]
Message-ID: <20140702233901.5d48f0ea@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407021615550.5931@chino.kir.corp.google.com>
On Wed, 2 Jul 2014 16:20:47 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:
> On Wed, 2 Jul 2014, Luiz Capitulino wrote:
>
> > > With this patch, the dmesg changes break one of my scripts that we use to
> > > determine the start and end address of a node (doubly bad because there's
> > > no sysfs interface to determine this otherwise and we have to do this at
> > > boot to acquire the system topology).
> > >
> > > Specifically, the removal of the
> > >
> > > "Initmem setup node X [mem 0xstart-0xend]"
> > >
> > > lines that are replaced when each node is onlined to
> > >
> > > "Node 0 memory range 0xstart-0xend"
> > >
> > > And if I just noticed this breakage when booting the latest -mm kernel,
> > > I'm assuming I'm not the only person who is going to run into it. Is it
> > > possible to not change the dmesg output?
> >
> > Sure. I can add back the original text. The only detail is that with this
> > patch that line is now printed a little bit later during boot and the
> > NODA_DATA lines also changed. Are you OK with that?
> >
>
> Yes, please. I think it should be incremental on your patch since it's
> already in -mm with " fix" appended so the title of the patch would be
> "x86: numa: setup_node_data(): drop dead code and rename function fix" and
> then Andrew can fold it into the original when sending it to the x86
> maintainers.
>
> > What's the guidelines on changing what's printed in dmesg?
> >
>
> That's the scary part, there doesn't seem to be any. It's especially
> crucial for things that only get printed once and aren't available
> anywhere else at runtime; there was talk of adding a sysfs interface that
> defines the start and end addresses of nodes but it's complicated because
> nodes can overlap each other. If that had been available years ago then I
> don't think anybody would raise their hand about this issue.
>
> These lines went under a smaller change a few years ago for
> s/Bootmem/Initmem/. I don't even have to look at the git history to know
> that because it broke our scripts back then as well. You just happened to
> touch lines that I really care about and breaks my topology information :)
> I wouldn't complain if it was just my userspace, but I have no doubt
> others have parsed their dmesg in a similar way because people have
> provided me with data that they retrieved by scraping the kernel log.
No problem. I'll send a patch shortly as you suggested.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Luiz Capitulino <lcapitulino@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
riel@redhat.com, andi@firstfloor.org, akpm@linux-foundation.org
Subject: Re: [PATCH] x86: numa: setup_node_data(): drop dead code and rename function
Date: Wed, 2 Jul 2014 23:39:01 -0400 [thread overview]
Message-ID: <20140702233901.5d48f0ea@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407021615550.5931@chino.kir.corp.google.com>
On Wed, 2 Jul 2014 16:20:47 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:
> On Wed, 2 Jul 2014, Luiz Capitulino wrote:
>
> > > With this patch, the dmesg changes break one of my scripts that we use to
> > > determine the start and end address of a node (doubly bad because there's
> > > no sysfs interface to determine this otherwise and we have to do this at
> > > boot to acquire the system topology).
> > >
> > > Specifically, the removal of the
> > >
> > > "Initmem setup node X [mem 0xstart-0xend]"
> > >
> > > lines that are replaced when each node is onlined to
> > >
> > > "Node 0 memory range 0xstart-0xend"
> > >
> > > And if I just noticed this breakage when booting the latest -mm kernel,
> > > I'm assuming I'm not the only person who is going to run into it. Is it
> > > possible to not change the dmesg output?
> >
> > Sure. I can add back the original text. The only detail is that with this
> > patch that line is now printed a little bit later during boot and the
> > NODA_DATA lines also changed. Are you OK with that?
> >
>
> Yes, please. I think it should be incremental on your patch since it's
> already in -mm with " fix" appended so the title of the patch would be
> "x86: numa: setup_node_data(): drop dead code and rename function fix" and
> then Andrew can fold it into the original when sending it to the x86
> maintainers.
>
> > What's the guidelines on changing what's printed in dmesg?
> >
>
> That's the scary part, there doesn't seem to be any. It's especially
> crucial for things that only get printed once and aren't available
> anywhere else at runtime; there was talk of adding a sysfs interface that
> defines the start and end addresses of nodes but it's complicated because
> nodes can overlap each other. If that had been available years ago then I
> don't think anybody would raise their hand about this issue.
>
> These lines went under a smaller change a few years ago for
> s/Bootmem/Initmem/. I don't even have to look at the git history to know
> that because it broke our scripts back then as well. You just happened to
> touch lines that I really care about and breaks my topology information :)
> I wouldn't complain if it was just my userspace, but I have no doubt
> others have parsed their dmesg in a similar way because people have
> provided me with data that they retrieved by scraping the kernel log.
No problem. I'll send a patch shortly as you suggested.
next prev parent reply other threads:[~2014-07-03 3:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 2:20 [PATCH] x86: numa: setup_node_data(): drop dead code and rename function Luiz Capitulino
2014-06-20 2:20 ` Luiz Capitulino
2014-06-26 14:51 ` Rik van Riel
2014-06-26 14:51 ` Rik van Riel
2014-06-26 15:05 ` Luiz Capitulino
2014-06-26 15:05 ` Luiz Capitulino
2014-06-26 15:51 ` Rik van Riel
2014-06-26 15:51 ` Rik van Riel
2014-06-30 23:42 ` David Rientjes
2014-06-30 23:42 ` David Rientjes
2014-07-02 17:33 ` Luiz Capitulino
2014-07-02 17:33 ` Luiz Capitulino
2014-07-02 23:20 ` David Rientjes
2014-07-02 23:20 ` David Rientjes
2014-07-03 3:39 ` Luiz Capitulino [this message]
2014-07-03 3:39 ` Luiz Capitulino
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=20140702233901.5d48f0ea@redhat.com \
--to=lcapitulino@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=yinghai@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 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.