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
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox