From: "Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com> To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "lisa.mitchell@hp.com" <lisa.mitchell@hp.com>, "ebiederm@xmission.com" <ebiederm@xmission.com>, "cpw@sgi.com" <cpw@sgi.com>, "vgoyal@redhat.com" <vgoyal@redhat.com> Subject: RE: [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore Date: Mon, 18 Feb 2013 00:16:15 +0000 [thread overview] Message-ID: <33710E6CAA200E4583255F4FB666C4E20AC96A42@G01JPEXMBYT03> (raw) In-Reply-To: <20130215125701.75d134af8fd3d99f7853e014@mxc.nes.nec.co.jp> From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Subject: Re: [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore Date: Fri, 15 Feb 2013 12:57:01 +0900 > On Thu, 14 Feb 2013 19:11:43 +0900 > HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote: <cut> >> TODO >> ==== >> >> - fix makedumpfile to use mmap() on /proc/vmcore and benchmark it to >> confirm whether we can see enough performance improvement. > > As a first step, I'll make a prototype patch for benchmarking unless you > have already done it. > I have an idea, but I've not started developing it yet. I think threre are the two points we should optimize. One is write_kdump_pages() that reads target page frames, compresses them if necessary, and writes each page frame data in order, and the other is __exclude_unnecessary_pages() that reads mem_map array into page_cache and processes it for filtering. Optimising the former seems trivial by mmap(), but we have to consider more for the latter case since it is virtually contiguous but not guranteed to be physically contiguous; mem_map is mapped in the virtual memory map region. Hence, the current implementation reads mem_map array one by one in 4KB page with virtual-to-physical translation. This is critical in performance and not sutable for optimization by mmap(). We should fix this anyway. My idea here is to focus on the fact that virtual memory map region is actually mapped using PMD level page entry, i.e. 4MB page, if currently used processor supports large pages. By this, the page entries gained by each page translation is guranteed to be physically contiguous in at least 4MB length. Looking at the benchmark, the performance improvement is already saturated in 4MB case. So I guess we can see enough performance improvement by mmap()ing mem_map array in this 4MB page units. Thanks. HATAYAMA, Daisuke
WARNING: multiple messages have this Message-ID (diff)
From: "Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com> To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "lisa.mitchell@hp.com" <lisa.mitchell@hp.com>, "ebiederm@xmission.com" <ebiederm@xmission.com>, "cpw@sgi.com" <cpw@sgi.com>, "vgoyal@redhat.com" <vgoyal@redhat.com> Subject: RE: [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore Date: Mon, 18 Feb 2013 00:16:15 +0000 [thread overview] Message-ID: <33710E6CAA200E4583255F4FB666C4E20AC96A42@G01JPEXMBYT03> (raw) In-Reply-To: <20130215125701.75d134af8fd3d99f7853e014@mxc.nes.nec.co.jp> From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Subject: Re: [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore Date: Fri, 15 Feb 2013 12:57:01 +0900 > On Thu, 14 Feb 2013 19:11:43 +0900 > HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote: <cut> >> TODO >> ==== >> >> - fix makedumpfile to use mmap() on /proc/vmcore and benchmark it to >> confirm whether we can see enough performance improvement. > > As a first step, I'll make a prototype patch for benchmarking unless you > have already done it. > I have an idea, but I've not started developing it yet. I think threre are the two points we should optimize. One is write_kdump_pages() that reads target page frames, compresses them if necessary, and writes each page frame data in order, and the other is __exclude_unnecessary_pages() that reads mem_map array into page_cache and processes it for filtering. Optimising the former seems trivial by mmap(), but we have to consider more for the latter case since it is virtually contiguous but not guranteed to be physically contiguous; mem_map is mapped in the virtual memory map region. Hence, the current implementation reads mem_map array one by one in 4KB page with virtual-to-physical translation. This is critical in performance and not sutable for optimization by mmap(). We should fix this anyway. My idea here is to focus on the fact that virtual memory map region is actually mapped using PMD level page entry, i.e. 4MB page, if currently used processor supports large pages. By this, the page entries gained by each page translation is guranteed to be physically contiguous in at least 4MB length. Looking at the benchmark, the performance improvement is already saturated in 4MB case. So I guess we can see enough performance improvement by mmap()ing mem_map array in this 4MB page units. Thanks. HATAYAMA, Daisuke _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-02-18 0:16 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-14 10:11 [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore HATAYAMA Daisuke 2013-02-14 10:11 ` HATAYAMA Daisuke 2013-02-14 10:11 ` [PATCH 01/13] vmcore: allocate buffer for ELF headers on page-size alignment HATAYAMA Daisuke 2013-02-14 10:11 ` HATAYAMA Daisuke 2013-02-15 15:01 ` Vivek Goyal 2013-02-15 15:01 ` Vivek Goyal 2013-02-14 10:11 ` [PATCH 02/13] vmcore: round up buffer size of ELF headers by PAGE_SIZE HATAYAMA Daisuke 2013-02-14 10:11 ` HATAYAMA Daisuke 2013-02-15 15:18 ` Vivek Goyal 2013-02-15 15:18 ` Vivek Goyal 2013-02-18 15:58 ` HATAYAMA Daisuke 2013-02-18 15:58 ` HATAYAMA Daisuke 2013-02-14 10:11 ` [PATCH 03/13] vmcore: fill unused part of buffer for ELF headers with 0 HATAYAMA Daisuke 2013-02-14 10:11 ` HATAYAMA Daisuke 2013-02-14 10:12 ` [PATCH 04/13] vmcore: introduce types for objects copied in 2nd kernel HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 15:28 ` Vivek Goyal 2013-02-15 15:28 ` Vivek Goyal 2013-02-18 16:06 ` HATAYAMA Daisuke 2013-02-18 16:06 ` HATAYAMA Daisuke 2013-02-19 23:07 ` Vivek Goyal 2013-02-19 23:07 ` Vivek Goyal 2013-02-14 10:12 ` [PATCH 05/13] vmcore: modify ELF32 code according to new type HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 15:30 ` Vivek Goyal 2013-02-15 15:30 ` Vivek Goyal 2013-02-18 16:11 ` HATAYAMA Daisuke 2013-02-18 16:11 ` HATAYAMA Daisuke 2013-02-14 10:12 ` [PATCH 06/13] vmcore: modify vmcore clean-up function to free buffer on 2nd kernel HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 15:32 ` Vivek Goyal 2013-02-15 15:32 ` Vivek Goyal 2013-02-14 10:12 ` [PATCH 07/13] vmcore: modify read_vmcore() to read " HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 15:51 ` Vivek Goyal 2013-02-15 15:51 ` Vivek Goyal 2013-02-14 10:12 ` [PATCH 08/13] vmcore: remove unused helper function HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 15:52 ` Vivek Goyal 2013-02-15 15:52 ` Vivek Goyal 2013-02-14 10:12 ` [PATCH 09/13] vmcore: copy ELF note segments in buffer on 2nd kernel HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 16:53 ` Vivek Goyal 2013-02-15 16:53 ` Vivek Goyal 2013-02-18 17:02 ` HATAYAMA Daisuke 2013-02-18 17:02 ` HATAYAMA Daisuke 2013-02-19 23:05 ` Vivek Goyal 2013-02-19 23:05 ` Vivek Goyal 2013-02-14 10:12 ` [PATCH 10/13] vmcore: round-up offset of vmcore object in page-size boundary HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-14 10:12 ` [PATCH 11/13] vmcore: count holes generated by round-up operation for vmcore size HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-14 10:12 ` [PATCH 12/13] vmcore: copy non page-size aligned head and tail pages in 2nd kernel HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-14 10:12 ` [PATCH 13/13] vmcore: introduce mmap_vmcore() HATAYAMA Daisuke 2013-02-14 10:12 ` HATAYAMA Daisuke 2013-02-15 3:57 ` [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore Atsushi Kumagai 2013-02-15 3:57 ` Atsushi Kumagai 2013-02-18 0:16 ` Hatayama, Daisuke [this message] 2013-02-18 0:16 ` Hatayama, Daisuke 2013-03-27 5:51 ` makedumpfile mmap() benchmark Jingbai Ma 2013-03-27 5:51 ` Jingbai Ma 2013-03-27 6:23 ` HATAYAMA Daisuke 2013-03-27 6:23 ` HATAYAMA Daisuke 2013-03-27 6:35 ` Jingbai Ma 2013-03-27 6:35 ` Jingbai Ma
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=33710E6CAA200E4583255F4FB666C4E20AC96A42@G01JPEXMBYT03 \ --to=d.hatayama@jp.fujitsu.com \ --cc=cpw@sgi.com \ --cc=ebiederm@xmission.com \ --cc=kexec@lists.infradead.org \ --cc=kumagai-atsushi@mxc.nes.nec.co.jp \ --cc=linux-kernel@vger.kernel.org \ --cc=lisa.mitchell@hp.com \ --cc=vgoyal@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.