--tcC6YSqBgqqkz7Sb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 10, 2007 at 09:56:47AM +0930, Brett Lymn wrote:
> On Mon, Jul 09, 2007 at 04:34:06PM -0400, Oliver Gould wrote:
> >=20
> > I think the general idea (as I have inferred) is that we don't want the=
 lkm
> > load operation to take as long zfs_start() may take, so it is thusly
> > offloaded to a worker thread.  Is it worth 'wasting' a kthread on this
> > one task?  Are there any other options?
> >=20
>=20
> I think we may be getting taskqueue in the future, so for the sake of
> expediency you could just use a kthread and comment it to be converted
> to a taskqueue later.

Forgive me if I've misunderstood, but the way I see it, workqueue(9)
lets us set up queues for things to schedule jobs on, without really
being proscriptive about what those things should be or how they
should correspond to threads and queues.

Basically, there's a separate question of whether every driver should
have it's own queue(s) and threads, or whether that can be some
general utility queues that can have work items added to them.  The
freebsd examples you gave seem to be concrete examples of particular
workqueues that are created in this vein.

I think a small number of general-purpose queues that run at
particular priorities or intervals/circumstances would be a great idea
for these mostly one-off tasks that need to be deferred, and then
specific drivers/subsystems that have lots of work to defer can
warrant their own thread(s) on a dedicated workqueue.

--
Dan.


--tcC6YSqBgqqkz7Sb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGkuoHEAVxvV4N66cRAnKeAKDZg/hvtbKThAS+8IAcOsarKZPmFQCfZDTY
CdVYPWPk/ObnkWf2eBf1zws=
=f27Q
-----END PGP SIGNATURE-----

--tcC6YSqBgqqkz7Sb--