On 11/05/2007, at 4:54 AM, Bill Sommerfeld wrote:
On Thu, 2007-05-10 at 10:10 -0700, Jürgen Keil wrote:
Btw: In one experiment I tried to boot the kernel under kmdb
control (-kd), patched minclsyspri := 61 and used a
breakpoint inside spa_active() to patch the spa_zio_* taskq
to use prio 60
On Wed, 5 Nov 2008, David Gwynne wrote:
be done in a very short time. perhaps you can amortize that cost by
doing it when the data from userland makes it into the kernel. another
idea could be doing the compression when you reach a relatively low
threshold of uncompressed data in the cache.
On 05/11/2008, at 3:27 AM, Bob Friesenhahn wrote:
On Wed, 5 Nov 2008, David Gwynne wrote:
be done in a very short time. perhaps you can amortize that cost by
doing it when the data from userland makes it into the kernel.
another
idea could be doing the compression when you reach a
Bob Friesenhahn wrote:
On Wed, 5 Nov 2008, David Gwynne wrote:
be done in a very short time. perhaps you can amortize that cost by
doing it when the data from userland makes it into the kernel. another
idea could be doing the compression when you reach a relatively low
threshold of
On 05/11/2008, at 2:22 PM, Ian Collins wrote:
Bob Friesenhahn wrote:
On Wed, 5 Nov 2008, David Gwynne wrote:
be done in a very short time. perhaps you can amortize that cost by
doing it when the data from userland makes it into the kernel.
another
idea could be doing the compression
I've filed:
6586537 async zio taskqs can block out userland commands
to track this issue.
eric
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
Erblichs wrote:
So, my first order would be to take 1GB or 10GB .wav files
AND time both the kernel implementation of Gzip and the
user application. Approx the same times MAY indicate
that the kernel implementation gzip funcs should
be treatedly maybe more
Darren Moffat,
Yes and no. A earlier statement within this discussion
was whether gzip is appropriate for .wav files. This just
gets a relative time to compress. And relative
sizes of the files after the compression.
My assumption is that gzip will run as
On May 2, 2007, at 10:36 PM, Ian Collins wrote:
The files are between 15 and 50MB. It's worth pointing out that .wav
files only compress by a few percent.
Not entirely related to your maxed CPU problem, but
gzip on PCM audio isn't, as you point out, going to earn you much of
a
Dale Ghent wrote:
On May 2, 2007, at 10:36 PM, Ian Collins wrote:
The files are between 15 and 50MB. It's worth pointing out that .wav
files only compress by a few percent.
Not entirely related to your maxed CPU problem, but
I don't think it was a maxed CPU problem, only one core was
Ian,
On 5/3/07, Ian Collins [EMAIL PROTECTED] wrote:
I don't think it was a maxed CPU problem, only one core was loaded and
the prstat numbers I could get (the reporting period was erratic) didn't
show anything nasty.
Do you have the output of 'mpstat 5'?
--
Just me,
Wire ...
Blog:
Ian Collins,
My two free cents..
If the gzip was in application space, most gzip's implementations
support (maybe a new compile) a less extensive/expensive deflation
that would consume fewer CPU cycles.
Secondly, if the file objects are being written
I just had a quick play with gzip compression on a filesystem and the
result was the machine grinding to a halt while copying some large
(.wav) files to it from another filesystem in the same pool.
The system became very unresponsive, taking several seconds to echo
keystrokes. The box is a maxed
Ian Collins wrote:
I just had a quick play with gzip compression on a filesystem and the
result was the machine grinding to a halt while copying some large
(.wav) files to it from another filesystem in the same pool.
The system became very unresponsive, taking several seconds to echo
Bart Smaalders wrote:
Ian Collins wrote:
I just had a quick play with gzip compression on a filesystem and the
result was the machine grinding to a halt while copying some large
(.wav) files to it from another filesystem in the same pool.
The system became very unresponsive, taking several
On 5/3/07, Ian Collins [EMAIL PROTECTED] wrote:
The system has 8MB of RAM and a was using 'cp -r' to copy the directory.
Hm, that would be a record breaking system. Did you mean 8 GB ?
--
Regards,
Cyril
___
zfs-discuss mailing list
Cyril Plisko wrote:
On 5/3/07, Ian Collins [EMAIL PROTECTED] wrote:
The system has 8MB of RAM and a was using 'cp -r' to copy the directory.
Hm, that would be a record breaking system. Did you mean 8 GB ?
Oops Yes.
___
zfs-discuss mailing list
17 matches
Mail list logo
