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.
This will be different with encryption. The crypto framework already
tries to do "fair" scheduling, it can be called in sync and async mode.
We use per provider taskqs for hardware and for async software
requests we have a taskq per cpu that can have scheduling priority/class
set on it by putting the svc://system/cryptosvc service into an
appropriate project.
I haven't done any performance testing of crypto yet so I don't know how
it will work in this case but we do know that the current method works
well for networking.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
