From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx182.postini.com [74.125.245.182]) by kanga.kvack.org (Postfix) with SMTP id 436496B0032 for ; Tue, 2 Jul 2013 03:00:39 -0400 (EDT) Received: by mail-wg0-f42.google.com with SMTP id z11so4280172wgg.1 for ; Tue, 02 Jul 2013 00:00:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130701125345.c4a383c7b8345f9c5ae54023@linux-foundation.org> References: <20130523052421.13864.83978.stgit@localhost6.localdomain6> <20130523052547.13864.83306.stgit@localhost6.localdomain6> <20130523152445.17549682ae45b5aab3f3cde0@linux-foundation.org> <51A2BBA7.50607@jp.fujitsu.com> <51A71B49.3070003@cn.fujitsu.com> <20130603174351.d04b2ac71d1bab0df242e0ba@mxc.nes.nec.co.jp> <51D0C500.4060108@jp.fujitsu.com> <20130701125345.c4a383c7b8345f9c5ae54023@linux-foundation.org> Date: Tue, 2 Jul 2013 11:00:37 +0400 Message-ID: Subject: Re: [PATCH v8 9/9] vmcore: support mmap() on /proc/vmcore From: Maxim Uvarov Content-Type: multipart/alternative; boundary=f46d043bdf74fb9a1604e081e625 Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: HATAYAMA Daisuke , Atsushi Kumagai , riel@redhat.com, kexec@lists.infradead.org, hughd@google.com, linux-kernel@vger.kernel.org, lisa.mitchell@hp.com, vgoyal@redhat.com, linux-mm@kvack.org, zhangyanfei@cn.fujitsu.com, ebiederm@xmission.com, kosaki.motohiro@jp.fujitsu.com, walken@google.com, cpw@sgi.com, jingbai.ma@hp.com --f46d043bdf74fb9a1604e081e625 Content-Type: text/plain; charset=ISO-8859-1 2013/7/1 Andrew Morton > On Mon, 1 Jul 2013 18:34:43 +0400 Maxim Uvarov wrote: > > > 2013/7/1 HATAYAMA Daisuke > > > > > (2013/06/29 1:40), Maxim Uvarov wrote: > > > > > >> Did test on 1TB machine. Total vmcore capture and save took 143 > minutes > > >> while vmcore size increased from 9Gb to 59Gb. > > >> > > >> Will do some debug for that. > > >> > > >> Maxim. > > >> > > > > > > Please show me your kdump configuration file and tell me what you did > in > > > the test and how you confirmed the result. > > > > > > > > Hello Hatayama, > > > > I re-run tests in dev env. I took your latest kernel patchset from > > patchwork for vmcore + devel branch of makedumpfile + fix to open and > write > > to /dev/null. Run this test on 1Tb memory machine with memory used by > some > > user space processes. crashkernel=384M. > > > > Please see my results for makedumpfile process work: > > [gzip compression] > > -c -d31 /dev/null > > real 37.8 m > > user 29.51 m > > sys 7.12 m > > > > [no compression] > > -d31 /dev/null > > real 27 m > > user 23 m > > sys 4 m > > > > [no compression, disable cyclic mode] > > -d31 --non-cyclic /dev/null > > real 26.25 m > > user 23 m > > sys 3.13 m > > > > [gzip compression] > > -c -d31 /dev/null > > % time seconds usecs/call calls errors syscall > > ------ ----------- ----------- --------- --------- ---------------- > > 54.75 38.840351 110 352717 mmap > > 44.55 31.607620 90 352716 1 munmap > > 0.70 0.497668 0 25497667 brk > > 0.00 0.000356 0 111920 write > > 0.00 0.000280 0 111904 lseek > > 0.00 0.000025 4 7 open > > 0.00 0.000000 0 473 read > > 0.00 0.000000 0 7 close > > 0.00 0.000000 0 3 fstat > > 0.00 0.000000 0 1 getpid > > 0.00 0.000000 0 1 execve > > 0.00 0.000000 0 1 uname > > 0.00 0.000000 0 2 unlink > > 0.00 0.000000 0 1 arch_prctl > > ------ ----------- ----------- --------- --------- ---------------- > > 100.00 70.946300 26427420 1 total > > > > I have no point of comparison here. Is this performance good, or is > the mmap-based approach still a lot more expensive? > > > Compressing to non-mmap version improvement is 30 minutes against 130 minutes for total dump process. And kernel load is very minimal. So definitely we need these patches. -- Best regards, Maxim Uvarov --f46d043bdf74fb9a1604e081e625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2013/7/1 Andrew Morton <akpm@li= nux-foundation.org>
On Mon, 1 Jul 2013 18:34:43 +0400 M= axim Uvarov <muvarov@gmail.com&= gt; wrote:

> 2013/7/1 HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>
> > (2013/06/29 1:40), Maxim Uvarov wrote:
> >
> >> Did test on 1TB machine. Total vmcore capture and save took 1= 43 minutes
> >> while vmcore size increased from 9Gb to 59Gb.
> >>
> >> Will do some debug for that.
> >>
> >> Maxim.
> >>
> >
> > Please show me your kdump configuration file and tell me what you= did in
> > the test and how you confirmed the result.
> >
> >
> Hello Hatayama,
>
> I re-run tests in dev env. I took your latest kernel patchset from
> patchwork for vmcore + devel branch of makedumpfile + fix to open and = write
> to /dev/null. Run this test on 1Tb memory machine with memory used by = some
> user space processes. crashkernel=3D384M.
>
> Please see my results for makedumpfile process work:
> [gzip compression]
> -c -d31 /dev/null
> real 37.8 m
> user 29.51 m
> sys 7.12 m
>
> [no compression]
> -d31 /dev/null
> real 27 m
> user 23 m
> sys =A0 4 m
>
> [no compression, disable cyclic mode]
> -d31 --non-cyclic /dev/null
> real 26.25 m
> user 23 m
> sys 3.13 m
>
> [gzip compression]
> -c -d31 /dev/null
> % time =A0 =A0 seconds =A0usecs/call =A0 =A0 calls =A0 =A0errors sysca= ll
> ------ ----------- ----------- --------- --------- ---------------- > =A054.75 =A0 38.840351 =A0 =A0 =A0 =A0 110 =A0 =A0352717 =A0 =A0 =A0 = =A0 =A0 mmap
> =A044.55 =A0 31.607620 =A0 =A0 =A0 =A0 =A090 =A0 =A0352716 =A0 =A0 =A0= =A0 1 munmap
> =A0 0.70 =A0 =A00.497668 =A0 =A0 =A0 =A0 =A0 0 =A025497667 =A0 =A0 =A0= =A0 =A0 brk
> =A0 0.00 =A0 =A00.000356 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0111920 =A0 =A0 = =A0 =A0 =A0 write
> =A0 0.00 =A0 =A00.000280 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0111904 =A0 =A0 = =A0 =A0 =A0 lseek
> =A0 0.00 =A0 =A00.000025 =A0 =A0 =A0 =A0 =A0 4 =A0 =A0 =A0 =A0 7 =A0 = =A0 =A0 =A0 =A0 open
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 473 =A0 =A0= =A0 =A0 =A0 read
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 7 =A0 = =A0 =A0 =A0 =A0 close
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 3 =A0 = =A0 =A0 =A0 =A0 fstat
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 1 =A0 = =A0 =A0 =A0 =A0 getpid
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 1 =A0 = =A0 =A0 =A0 =A0 execve
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 1 =A0 = =A0 =A0 =A0 =A0 uname
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 2 =A0 = =A0 =A0 =A0 =A0 unlink
> =A0 0.00 =A0 =A00.000000 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 1 =A0 = =A0 =A0 =A0 =A0 arch_prctl
> ------ ----------- ----------- --------- --------- ---------------- > 100.00 =A0 70.946300 =A0 =A0 =A0 =A0 =A0 =A0 =A026427420 =A0 =A0 =A0 = =A0 1 total
>

I have no point of comparison here. =A0Is this performance good= , or is
the mmap-based approach still a lot more expensive?


Compressing to non-mmap version improvement is 30 minute= s against 130 minutes for total dump process. And kernel load is very minim= al. So definitely we need these patches.

--
Best regards,
Maxim Uvarov --f46d043bdf74fb9a1604e081e625-- -- 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: email@kvack.org