mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: OBATA Noboru <noboru.obata.ar@hitachi.com>
To: pavel@ucw.cz
Cc: hyoshiok@miraclelinux.com, linux-kernel@vger.kernel.org
Subject: Re: Linux Kernel Dump Summit 2005
Date: Wed, 12 Oct 2005 17:28:44 +0900 (JST)	[thread overview]
Message-ID: <20051012.172844.59463643.noboru.obata.ar@hitachi.com> (raw)
In-Reply-To: <20051010084535.GA2298@elf.ucw.cz>

Hi, Pavel,

On Mon, 10 Oct 2005, Pavel Machek wrote:
> 
> > Compressing a 32GB dump file took about 40 minutes on Pentium 4
> > Xeon 3.0GHz, which is not good enough because the dump without
> > compression took only 5 minutes; eight times slower.
> 
> ....you probably want to look at suspend2.net project. They have
> special compressor aimed at compressing exactly this kind of data,
> fast enough to be improvement.

Thank you for pointing me to the interesting project.

I looked at their patch to find that the special compressor uses
the LZF compression algorithm.  (Correct me if I'm wrong.)

So I made a quick comparison between cp, lzf(*) and gzip as
follows.  The INFILE is a file that showed the worst compression
ratio last time.

(*) A simple compress tool based on LZF algorithm included in
    liblzf, available from http://www.goof.com/pcg/marc/liblzf.html


$ cp INFILE /dev/null           # this puts whole INFILE in a cache

$ /usr/bin/time cp INFILE /mnt/OUTFILE-cp
0.23user 14.16system 0:35.94elapsed 40%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (115major+15minor)pagefaults 0swaps

$ /usr/bin/time ./lzf -c < INFILE > /mnt/OUTFILE-lzf
35.04user 13.10system 0:54.30elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (84major+74minor)pagefaults 0swaps

$ /usr/bin/time gzip -1c < INFILE > /mnt/OUTFILE-gzip-1
186.84user 11.73system 3:20.36elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (90major+93minor)pagefaults 0swaps


The results can be summarized as follows.  The lzf tool is
slower than cp (normal file copy) only by a factor of 1.5,
achieving the compress ratio close to gzip -1.


   CMD     | NET TIME (in seconds)          | OUTPUT SIZE (in bytes)
  ---------+--------------------------------+------------------------
   cp      |  35.94 (usr 0.23, sys 14.16)   | 2,121,438,352 (100.0%)
   lzf     |  54.30 (usr 35.04, sys 13.10)  | 1,959,473,330 ( 92.3%)
   gzip -1 | 200.36 (usr 186.84, sys 11.73) | 1,938,686,487 ( 91.3%)
  ---------+--------------------------------+------------------------


Although it is too early to say lzf's compress ratio is good
enough, its compression speed is impressive indeed.  And the
result also suggests that it is too early to give up the idea of
full dump with compression.

Pavel, thank you again for your advice and I'll welcome further
suggestions.

-- 
OBATA Noboru (noboru.obata.ar@hitachi.com)


  reply	other threads:[~2005-10-12  8:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 11:55 Hiro Yoshioka
2005-10-06 12:17 ` OBATA Noboru
2005-10-06 14:39   ` Hiro Yoshioka
2005-10-10  8:45   ` Pavel Machek
2005-10-12  8:28     ` OBATA Noboru [this message]
2005-10-12  9:02       ` Felix Oxley
2005-10-12  9:09         ` Pavel Machek
2005-10-12  9:56           ` Felix Oxley
2005-10-12 10:07             ` Pavel Machek
2005-10-12 18:03               ` Andy Isaacson
2005-10-12 22:34                 ` Felix Oxley
2005-10-12 11:05             ` jerome lacoste
2005-10-12 21:10               ` Felix Oxley
2005-10-18 13:47         ` OBATA Noboru
2005-10-18 14:10           ` Hugh Dickins
2005-10-19 19:00             ` Theodore Ts'o
2005-10-27  7:48               ` OBATA Noboru
2005-10-11  0:49   ` Andrew Morton
2005-10-11  4:41     ` Hiro Yoshioka
2005-10-12  8:30       ` OBATA Noboru
2005-10-13  5:49         ` Maneesh Soni
2005-10-27  7:45           ` OBATA Noboru
2005-10-13 14:28     ` Troy Heber
2005-10-17 11:19     ` Takao Indoh
2005-10-18 13:48       ` OBATA Noboru
2005-10-19  3:17         ` Takao Indoh
2005-10-27  7:45           ` OBATA Noboru
2005-10-18 14:54     ` Carsten Otte
2005-10-14  9:19 hideki.takahashi

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=20051012.172844.59463643.noboru.obata.ar@hitachi.com \
    --to=noboru.obata.ar@hitachi.com \
    --cc=hyoshiok@miraclelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®