[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140702233901.5d48f0ea@redhat.com>
Date: Wed, 2 Jul 2014 23:39:01 -0400
From: Luiz Capitulino <lcapitulino@...hat.com>
To: David Rientjes <rientjes@...gle.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
isimatu.yasuaki@...fujitsu.com, yinghai@...nel.org,
riel@...hat.com, andi@...stfloor.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] x86: numa: setup_node_data(): drop dead code and rename
function
On Wed, 2 Jul 2014 16:20:47 -0700 (PDT)
David Rientjes <rientjes@...gle.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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists