Thanks, that's good news, and thanks for the commit ID, that was the thing I
was having trouble finding.
-Original Message-
From: Atsushi Kumagai [mailto:kumagai-atsu...@mxc.nes.nec.co.jp]
Sent: Thursday, February 07, 2013 7:45 PM
To: Mitchell, Lisa (MCLinux in Fort Collins)
Cc: vgo...@redhat.com; ke...@lists.infradead.org; linux-kernel@vger.kernel.org;
linux...@kvack.org; d.hatay...@jp.fujitsu.com; ebied...@xmission.com;
a...@linux-foundation.org; c...@sgi.com
Subject: Re: [PATCH v2] Add the values related to buddy system for filtering
free pages.
Hello Lisa,
On Thu, 07 Feb 2013 05:29:11 -0700
Lisa Mitchell wrote:
> > > > Also, I have one question. Can we always think of 1st and 2nd
> > > > kernels are same?
> > >
> > > Not at all. Distros frequently implement it with the same kernel
> > > in both role but it should be possible to use an old crusty stable
> > > kernel as the 2nd kernel.
> > >
> > > > If I understand correctly, kexec/kdump can use the 2nd kernel
> > > > different from the 1st's. So, differnet kernels need to do the
> > > > same thing as makedumpfile does. If assuming two are same, problem is
> > > > mush simplified.
> > >
> > > As a developer it becomes attractive to use a known stable kernel
> > > to capture the crash dump even as I experiment with a brand new kernel.
> >
> > To allow to use the 2nd kernel different from the 1st's, I think we
> > have to take care of each kernel version with the logic included in
> > makedumpfile for them. That's to say, makedumpfile goes on as before.
> >
> >
> > Thanks
> > Atsushi Kumagai
>
>
> Atsushi and Vivek:
>
> I'm trying to get the status of whether the patch submitted in
> https://lkml.org/lkml/2012/11/21/90 is going to be accepted upstream
> and get in some version of the Linux 3.8 kernel. I'm replying to the
> last email thread above on kexec_lists and lkml.org that I could find
> about this patch.
>
> I was counting on this kernel patch to improve performance of
> makedumpfilev1.5.1, so at least it wouldn't be a regression in
> performance over makedumpfile v1.4. It was listed as recommended in
> the makedumpfilev1.5.1 release posting:
> http://lists.infradead.org/pipermail/kexec/2012-December/007460.html
>
>
> All the conversations in the thread since this patch was committed
> seem to voice some reservations now, and reference other fixes being
> tried to improve performance.
>
> Does that mean you are abandoning getting this patch accepted
> upstream, in favor of pursuing other alternatives?
No, this patch has been merged into -next, we should just wait for it to be
merged into linus tree.
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0c63e90dd1c7b35ae2ea9475ba67cf68d8801a26
What interests us now is improvement for interfaces of /proc/vmcore, it's not
alternative but another idea which can be consistent with this patch.
Thanks
Atsushi Kumagai
>
> I had hoped this patch would be okay to get accepted upstream, and
> then other improvements could be built on top of it.
>
> Is that not the case?
>
> Or has further review concluded now that this change is a bad idea due
> to adding dependence of this new makedumpfile feature on some deep
> kernel memory internals?
>
> Thanks,
>
> Lisa Mitchell
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
