All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: btrfs-devel@arbitraryconstant.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Compressed Filesystem
Date: Wed, 29 Oct 2008 16:08:42 -0400	[thread overview]
Message-ID: <1225310922.6448.300.camel@think.oraclecorp.com> (raw)
In-Reply-To: <53696.2001:470:e828:1::2:2.1225304096.squirrel@avalon.arbitraryconstant.com>

On Wed, 2008-10-29 at 12:14 -0600, Anthony Roberts wrote:
> Hi, I have a few questions about this:
> 
> > Compression is optional and off by default (mount -o compress to enable
> > it).  When enabled, every file is compressed.
> 
> Do you know what the CPU load is like with this enabled?

Now that I've finally pushed the code out, you can try it ;)  One part
of the implementation I need to revisit is the place in the code where I
do compression means that most of the time the single threaded pdflush
is the one compressing.

This doesn't spread the load very well across the cpus.  It can be
fixed, but I wanted to get the code out there.

The decompression does spread across cpus, and I've gotten about 800MB/s
doing decompress and checksumming on a zero filled compressed file.  At
the time, the disk was reading 14MB/s.

> 
> Do you know whether data can be compressed at a sufficient rate to still
> saturate the disk on recent-ish AMD/Intel CPUs?

My recentish intel cpu can compress and checksum at about 120MB/s.  
> 
> If no, is the effective pre-compression I/O rate still comparable to the
> disk without compression?
> 

It depends on your disks...

> I'm pretty sure that won't even matter in many cases (eg you're seeking
> too much to care, or you're on a VM with lots of cores but congested
> disks, or you're dealing with media files that it doesn't bother
> compressing, etc), but I'm curious what sort of overhead this adds. :)
> 
> Mostly it seems like a good tradeoff, it trades plentiful cores for scarce
> disk resources.

This varies quite a bit from workload to workload, in some places it'll
make a big difference, but many workloads are seek bound and not
bandwidth bound.

-chris





  parent reply	other threads:[~2008-10-29 20:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-27 14:54 Compressed Filesystem Lee Trager
2008-10-28 15:47 ` Chris Mason
2008-10-28 16:33   ` Lee Trager
2008-10-28 17:38     ` Chris Mason
2008-10-28 17:40       ` Zach Brown
2008-10-28 17:46         ` Chris Mason
     [not found]       ` <53696.2001:470:e828:1::2:2.1225304096.squirrel@avalon.arbitraryconstant.com>
2008-10-29 20:08         ` Chris Mason [this message]
2008-11-04  0:08           ` Chris Samuel
  -- strict thread matches above, loose matches on Subject: below --
2008-12-15 22:14 devzero
2008-12-15 23:07 ` Lee Trager
2008-12-15 23:19 devzero
2008-12-16 15:20 ` Lee Trager
2008-12-16 15:26   ` Chris Mason
2008-12-16 16:25     ` Lee Trager
2008-12-16 19:45       ` Roland
2008-12-18 15:55         ` Chris Mason
2008-12-16 18:14 devzero

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=1225310922.6448.300.camel@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=btrfs-devel@arbitraryconstant.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.