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 when importing the gzip compressed pool >> (so that the gzip compressed pool was using prio 60 threads >> and usb and other stuff was using prio >= 61 threads). >> That didn't help interactive performance... > > oops. sounds like cpu-intensive compression (and encryption/ > decryption > once that's upon us) should ideally be handed off to worker threads > that > compete on a "fair" footing with compute-intensive userspace > threads, or > (better yet) are scheduled like the thread which initiated the I/O.
i just installed s10u6 which now has gzip compression on zfs datasets. very exciting, my samfs disk vsn can store a bit more now. however, despite being able to store more it does lock up a lot while it does the compression. perhaps doing the compression at a different point in the io pipeline would be better. at the moment it is done when zfs decides to flush the buffers to disk, which ends up being a lot of work that needs to 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. ie, as soon as you get 1MB of data in the cache, compress it then, rather than waiting till you have 200MB of data in the cache that needs to be compressed RIGHT NOW. either way, my opinion is you want to do all the compression work spread over a longer period of time, rather than all at once when you flush the cache to the spindles. i can tolerate 90% idle cpus. i cant tolerate cpus that are 98% idle except for every 5 seconds when theyre 0% idle for 2 seconds and i cant even see keypresses on a serial console cos there's no time for userland to run in. dlg _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
