Commit graph

12 commits

Author SHA1 Message Date
Warner Losh
14889b4229 Add taskqueue_drain. This waits for the specified task to finish, if
running, or returns.  The calling program is responsible for making sure
that nothing new is enqueued.

# man page coming soon.
2004-10-05 04:16:01 +00:00
John-Mark Gurney
227559d11f rearange some code that handles the thread taskqueue so that it is more
generic.  Introduce a new define TASKQUEUE_DEFINE_THREAD that takes a
single arg, which is the name of the queue.

Document these changes.
2004-08-08 02:37:22 +00:00
Robert Watson
b3059e09f6 Defer the vrele() on a jail's root vnode reference from prison_free()
to a new prison_complete() task run by a task queue.  This removes
a requirement for grabbing Giant in crfree().  Embed the 'struct task'
in 'struct prison' so that we don't have to allocate memory from
prison_free() (which means we also defer the FREE()).

With this change, I believe grabbing Giant from crfree() can now be
removed, but need to check the uidinfo code paths.

To avoid header pollution, move the definition of 'struct task'
to _task.h, and recursively include from taskqueue.h and jail.h; much
preferably to all files including jail.h picking up a requirement to
include taskqueue.h.

Bumped into by:	sam
Reviewed by:	bde, tjr
2004-01-23 20:44:26 +00:00
Sam Leffler
f82c9e70f9 "fast swi" taskqueue support. This is a taskqueue that uses spinlocks
making it useful for dispatching swi tasks from fast interrupt handlers.

Sponsered by:	FreeBSD Foundation
2003-09-05 23:09:22 +00:00
Kenneth D. Merry
cb32189e23 Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.

The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.

The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread.  For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.

The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand.  So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread.  (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)

scsi_cd.c:	Remove sysctl variable creation code from cdregister(), and
		move it to a new function, cdsysctlinit().  Queue
		cdsysctlinit() to the taskqueue_thread taskqueue once we
		have fully registered the cd(4) driver instance.

scsi_da.c:	Remove sysctl variable creation code from daregister(), and
		move it to move it to a new function, dasysctlinit().
		Queue dasysctlinit() to the taskqueue_thread taskqueue once
		we have fully registered the da(4) instance.

taskqueue.h:	Declare the new taskqueue_thread taskqueue, update some
		comments.

subr_taskqueue.c:
		Create the new kernel thread taskqueue.  This taskqueue
		runs outside of Giant, so any functions queued to it would
		need to explicitly acquire/release Giant if they need it.

cd.4:		Update the cd(4) man page to talk about the minimum command
		size sysctl/loader tunable.  Also note that the changer
		variables are available as loader tunables as well.

da.4:		Update the da(4) man page to cover the retry_count,
		default_timeout and minimum_cmd_size sysctl variables/loader
		tunables.  Remove references to /dev/r???, they aren't used
		any longer.

cd.9:		Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
		quirk.

taskqueue.9:	Update the taskqueue(9) man page to describe the new thread
		task queue, and the taskqueue_swi_giant queue.

MFC after:	3 days
2003-09-03 04:46:28 +00:00
Scott Long
7874f606d5 Introduce a new taskqueue that runs completely free of Giant, and in
turns runs its tasks free of Giant too.  It is intended that as drivers
become locked down, they will move out of the old, Giant-bound taskqueue
and into this new one.  The old taskqueue has been renamed to
taskqueue_swi_giant, and the new one keeps the name taskqueue_swi.
2003-02-26 03:15:42 +00:00
John Baldwin
5a994091e0 Revert the reindentation of struct task's definition from rev 1.4.
Requested by:	bde
2001-10-28 16:19:34 +00:00
John Baldwin
282873e2c0 - Change the taskqueue locking to protect the necessary parts of a task
while it is on a queue with the queue lock and remove the per-task locks.
- Remove TASK_DESTROY now that it is no longer needed.
- Go back to inlining TASK_INIT now that it is short again.

Inspired by:	dfr
2001-10-26 18:46:48 +00:00
John Baldwin
1de1c550b1 Add locking to taskqueues. There is one mutex per task, one mutex per
queue, and a mutex to protect the global list of taskqueues.  The only
visible change is that a TASK_DESTROY() macro has been added to mirror
the TASK_INIT() macro to destroy a task before it is free'd.

Submitted by:	Andrew Reiter <awr@watson.org>
2001-10-26 06:32:21 +00:00
Mike Smith
5e49eb2378 taskqueue_swi is a pointer, not a struct. Fix a comment that misleadingly
suggests you pass its address to taskqueue_enqueue, which leads to various
kinds of unpleasant mischief.
2000-06-09 22:32:36 +00:00
Doug Rabson
d20743db3c Style fixes.
Submitted by: bde
2000-05-30 07:27:46 +00:00
Doug Rabson
ca2e05343b Add taskqueue system for easy-to-use SWIs among other things.
Reviewed by: arch
2000-05-28 15:45:30 +00:00