lkml.org 
[lkml]   [2012]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] Add the values related to buddy system for filtering free pages.
Hello,

On Thu, 20 Dec 2012 18:00:11 -0800
ebiederm@xmission.com (Eric W. Biederman) wrote:

> "Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com> writes:
>
> >> From: kexec-bounces@lists.infradead.org
> >> [mailto:kexec-bounces@lists.infradead.org] On Behalf Of Atsushi Kumagai
> >> Sent: Thursday, December 20, 2012 11:21 AM
> >
> >> On Wed, 19 Dec 2012 16:18:56 -0800
> >> Andrew Morton <akpm@linux-foundation.org> wrote:
> >>
> >> > On Mon, 10 Dec 2012 10:39:13 +0900
> >> > Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:
> >> >
> >
> >> >
> >> > We might change the PageBuddy() implementation at any time, and
> >> > makedumpfile will break. Or in this case, become less efficient.
> >> >
> >> > Is there any way in which we can move some of this logic into the
> >> > kernel? In this case, add some kernel code which uses PageBuddy() on
> >> > behalf of makedumpfile, rather than replicating the PageBuddy() logic
> >> > in userspace?
> >>
> >> In last month, Cliff Wickman proposed such idea:
> >>
> >> [PATCH v2] makedumpfile: request the kernel do page scans
> >> http://lists.infradead.org/pipermail/kexec/2012-November/007318.html
> >>
> >> [PATCH] scan page tables for makedumpfile, 3.0.13 kernel
> >> http://lists.infradead.org/pipermail/kexec/2012-November/007319.html
> >>
> >> In his idea, the kernel does page scans to distinguish unnecessary pages
> >> (free pages and others) and returns the list of PFN's which should be
> >> excluded for makedumpfile.
> >> As a result, makedumpfile doesn't need to consider internal kernel
> >> behavior.
> >>
> >> I think it's a good idea from the viewpoint of maintainability and
> >> performance.
>
> > I also think wide part of his code can be reused in this work. But the bad
> > performance is caused by a lot of ioremap, not a lot of copying. See my
> > profiling result I posted some days ago. Two issues, ioremap one and filtering
> > maintainability, should be considered separately. Even on ioremap issue,
> > there is secondary one to consider in memory consumption on the 2nd
> > kernel.
>
> Thanks. I was wondering why moving the code into /proc/vmcore would
> make things faster.

Thanks HATAYAMA-san, I've understood the issues correctly.
We should continue improving the ioremap issue as Cliff and HATAYAMA-san
are doing now.

>
> > 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


\
 
 \ /
  Last update: 2012-12-27 10:21    [W:0.701 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site