From: Valdis.Kletnieks@vt.edu
To: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
Cc: Pavel Machek <pavel@ucw.cz>, Rik van Riel <riel@surriel.com>,
linux-kernel@vger.kernel.org
Subject: Re: WANTED: kernel projects for CS students
Date: Fri, 02 Nov 2007 23:08:23 -0400 [thread overview]
Message-ID: <12100.1194059303@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Mon, 29 Oct 2007 17:44:52 EDT." <20071029214452.GA27643@csclub.uwaterloo.ca>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
On Mon, 29 Oct 2007 17:44:52 EDT, Lennart Sorensen said:
> On Mon, Oct 29, 2007 at 09:19:11PM +0100, Pavel Machek wrote:
Sorry for the late reply, it's been a zoo of a week here... ;)
> If it doesn't it seems the compression feature is going to be rather
> unpredictable and my optimization would be perfectly within spec and
> make it pretty much useless.
>
> > Yes. Typically for all zeros. It will be similar for
> > highly-compressible data (pictures, timetables, ....)
And most executables. There's a reason why my vmlinux files are 11M and my
vmlinuz files are 2m. :)
> That would make it tricky to say if you should ever skip compression due
> to cpu load. There is a chance cpu load would be better off by doing
> the compression.
IBM's AIX supported file system compression on the JFS filesystem years ago. I
was able to get up to 30% throughput increases by converting the /usr
filesystem to compressed - because even a 33mhz Power chipset could read in 5
512-byte blocks and decompress it to the original 4K faster than the disk could
read in 8 512-byte blocks. Oh, and it worked for compression on r/w workloads
as well - that was one of the ways to get a RS6K model 250 (which was a
PowerPC601 chipset, a dead heat with a Mac 6600 (same chipset, same clock) to
handle a million e-mail msgs/day - even /var/spool/mqueue worked better.
Given that today there's an even *bigger* disparity in CPU speed versus disk
speed, I'd be surprised if it doesn't help today too. As a first try, you
might consider compressing each 4K filesystem block in-place, and only write as
many sectors as the compressed takes (with the obvious fix for the pathological
"grows with compression" case of "just write it without"). Probably even
more wins can be found if you find a way to store the compressed chunks in a
way that minimizes seeks, but that's a filesystem design issue and probably
a too-large project (It's easy to do the stupid way - just store the whole
file as compressed - the tough part is doing it and not making lseek() *too*
painful. Trying to figure out where in a .gz file byte 65536... ouch. ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
next prev parent reply other threads:[~2007-11-03 3:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-14 23:01 Rik van Riel
2007-10-15 10:40 ` WANG Cong
2007-10-15 17:13 ` Rik van Riel
2007-10-15 14:23 ` Sam Ravnborg
2007-10-15 15:10 ` Rik van Riel
2007-10-15 18:31 ` Sam Ravnborg
2007-10-15 16:31 ` Philippe Elie
2007-10-15 16:36 ` Philippe Elie
2007-10-15 16:52 ` Jan Engelhardt
2007-10-15 16:53 ` Xavier Bestel
2007-10-15 18:19 ` Sam Ravnborg
2007-10-15 15:40 ` Jörn Engel
2007-10-15 17:04 ` Doug Whitesell (LKML)
2007-10-15 17:04 ` Mark Gross
2007-10-15 18:30 ` Sam Ravnborg
2007-10-15 18:45 ` Mark Gross
2007-10-15 19:54 ` Giacomo Catenazzi
2007-10-16 20:06 ` Mark Gross
2007-10-16 20:09 ` Jan Engelhardt
2007-10-16 20:23 ` Rik van Riel
2007-10-16 20:25 ` Jan Engelhardt
2007-10-16 21:10 ` david
2007-10-16 21:30 ` david
2007-11-02 7:54 ` Giacomo Catenazzi
2007-10-16 20:31 ` Giacomo Catenazzi
2007-10-15 19:17 ` Alexey Dobriyan
2007-10-15 19:54 ` Folkert van Heusden
2007-10-16 20:10 ` Mark Gross
2007-10-16 0:39 ` david
2007-10-15 17:10 ` Zan Lynx
2007-10-15 17:23 ` Rik van Riel
2007-10-16 0:51 ` david
2007-10-15 17:30 ` Guilherme Amadio
2007-10-15 18:03 ` J. Bruce Fields
2007-10-17 17:45 ` Mark Gross
2007-10-18 4:51 ` Toshiharu Harada
2007-10-28 18:07 ` Pavel Machek
2007-10-28 18:57 ` Rafael J. Wysocki
2007-10-29 19:48 ` Lennart Sorensen
2007-10-29 20:19 ` Pavel Machek
2007-10-29 21:44 ` Lennart Sorensen
2007-11-03 3:08 ` Valdis.Kletnieks [this message]
2007-11-03 3:36 ` Rik van Riel
2007-11-03 9:44 ` Wander Winkelhorst
2007-11-03 10:05 ` david
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=12100.1194059303@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=pavel@ucw.cz \
--cc=riel@surriel.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: 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®