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-atsushi@xxxxxxxxxxxxxxxxx] Sent: Thursday, February 07, 2013 7:45 PM To: Mitchell, Lisa (MCLinux in Fort Collins) Cc: vgoyal at redhat.com; kexec at lists.infradead.org; linux-kernel at vger.kernel.org; linux-mm at kvack.org; d.hatayama at jp.fujitsu.com; ebiederm at xmission.com; akpm at linux-foundation.org; cpw at 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 <lisa.mitchell at hp.com> 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 > >
