From: Petr Tesarik <ptesarik@suse.cz>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: kexec@lists.infradead.org
Subject: Re: [PATCH] makedumpfile: keep dumpfile pages in a cache
Date: Mon, 3 Sep 2012 09:04:03 +0200 [thread overview]
Message-ID: <201209030904.03661.ptesarik@suse.cz> (raw)
In-Reply-To: <20120903124233.61eafa52ffaed6a38a23710d@mxc.nes.nec.co.jp>
Dne Po 3. září 2012 05:42:33 Atsushi Kumagai napsal(a):
> Hello Petr,
>
> On Tue, 28 Aug 2012 19:49:49 +0200
>
> Petr Tesarik <ptesarik@suse.cz> wrote:
> > Add a simple cache for pages read from the dumpfile.
> >
> > This is a big win if we read consecutive data from one page, e.g.
> > page descriptors, or even page table entries.
> >
> > Note that makedumpfile now always reads a complete page. This was already
> > the case with kdump-compressed and sadump formats, but makedumpfile was
> > throwing most of the data away. For the kdump-compressed case, we may
> > actually save a lot of decompression, too.
> >
> > I tried to keep the cache small to minimize memory footprint, but it
> > should be big enough to hold all pages to do 4-level paging plus some
> > data. This is needed e.g. for vmalloc areas or Xen page frame table
> > data, which are not contiguous in physical memory.
> >
> > Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
>
> It's interesting to me. I want to know how performance will be improved
> with this patch, so do you have speed measurements ?
Not really. I only measured the hit/miss ratio, and with filtering Xen domU
and dump level 0, I got the following on a small system (2G RAM):
cache hit: 1818880 cache miss: 1873
The improvement isn't much for non-Xen case, because the hits are mostly due
to virtual-to-physical translations, and most of Linux data is stored at
virtual addresses that can be resolved by adding/subtracting a fixed offset.
Of course, you will also win only the syscall overhead, because Linux keeps
the data in the kernel pagecache anyway. I'll measure the times for you on a
reasonably large system (~256G) and send the results here.
Regards,
Petr Tesarik
SUSE Linux
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-09-03 7:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 17:49 [PATCH] makedumpfile: keep dumpfile pages in a cache Petr Tesarik
2012-09-03 3:42 ` Atsushi Kumagai
2012-09-03 7:04 ` Petr Tesarik [this message]
2012-09-06 15:50 ` Petr Tesarik
2012-11-14 3:47 ` Atsushi Kumagai
[not found] ` <2267600.lHCcsG40Ue@azariah.suse.cz>
[not found] ` <20121119174044.3144d3df02b62128d1d2bfe2@mxc.nes.nec.co.jp>
[not found] ` <20121219160125.036d5de8@azariah>
[not found] ` <20130110094851.61168ff4486308c27aa567f6@mxc.nes.nec.co.jp>
2013-02-06 7:01 ` Atsushi Kumagai
2013-02-13 12:18 ` Petr Tesarik
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=201209030904.03661.ptesarik@suse.cz \
--to=ptesarik@suse.cz \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/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: link
Be 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.