2000-05-28 16:53:50 +00:00
|
|
|
.\" -*- nroff -*-
|
|
|
|
.\"
|
|
|
|
.\" Copyright (c) 2000 Doug Rabson
|
|
|
|
.\"
|
|
|
|
.\" All rights reserved.
|
|
|
|
.\"
|
|
|
|
.\" This program is free software.
|
|
|
|
.\"
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
.\" are met:
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
.\"
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
.\"
|
|
|
|
.\" $FreeBSD$
|
|
|
|
.\"
|
2009-08-17 09:01:20 +00:00
|
|
|
.Dd August 17, 2009
|
2000-05-28 16:53:50 +00:00
|
|
|
.Dt TASKQUEUE 9
|
|
|
|
.Os
|
|
|
|
.Sh NAME
|
|
|
|
.Nm taskqueue
|
|
|
|
.Nd asynchronous task execution
|
|
|
|
.Sh SYNOPSIS
|
2001-10-01 16:09:29 +00:00
|
|
|
.In sys/param.h
|
2001-12-26 23:14:04 +00:00
|
|
|
.In sys/kernel.h
|
|
|
|
.In sys/malloc.h
|
2001-10-01 16:09:29 +00:00
|
|
|
.In sys/queue.h
|
|
|
|
.In sys/taskqueue.h
|
2000-05-28 16:53:50 +00:00
|
|
|
.Bd -literal
|
2004-10-26 17:14:45 +00:00
|
|
|
typedef void (*task_fn_t)(void *context, int pending);
|
2000-05-28 16:53:50 +00:00
|
|
|
|
|
|
|
typedef void (*taskqueue_enqueue_fn)(void *context);
|
|
|
|
|
|
|
|
struct task {
|
|
|
|
STAILQ_ENTRY(task) ta_link; /* link for queue */
|
2005-05-01 02:12:44 +00:00
|
|
|
u_short ta_pending; /* count times queued */
|
|
|
|
u_short ta_priority; /* priority of task in queue */
|
2004-10-26 17:14:45 +00:00
|
|
|
task_fn_t ta_func; /* task handler */
|
2000-05-28 16:53:50 +00:00
|
|
|
void *ta_context; /* argument for handler */
|
|
|
|
};
|
|
|
|
.Ed
|
|
|
|
.Ft struct taskqueue *
|
2008-05-22 21:41:19 +00:00
|
|
|
.Fn taskqueue_create "const char *name" "int mflags" "taskqueue_enqueue_fn enqueue" "void *context"
|
2008-06-13 19:35:17 +00:00
|
|
|
.Ft struct taskqueue *
|
|
|
|
.Fn taskqueue_create_fast "const char *name" "int mflags" "taskqueue_enqueue_fn enqueue" "void *context"
|
2000-05-28 16:53:50 +00:00
|
|
|
.Ft void
|
|
|
|
.Fn taskqueue_free "struct taskqueue *queue"
|
|
|
|
.Ft struct taskqueue *
|
|
|
|
.Fn taskqueue_find "const char *name"
|
|
|
|
.Ft int
|
|
|
|
.Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task"
|
2004-01-02 07:23:40 +00:00
|
|
|
.Ft int
|
|
|
|
.Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *task"
|
2000-05-28 16:53:50 +00:00
|
|
|
.Ft void
|
|
|
|
.Fn taskqueue_run "struct taskqueue *queue"
|
2005-04-19 16:23:00 +00:00
|
|
|
.Ft void
|
|
|
|
.Fn taskqueue_run_fast "struct taskqueue *queue"
|
2005-05-19 18:31:42 +00:00
|
|
|
.Ft void
|
|
|
|
.Fn taskqueue_drain "struct taskqueue *queue" "struct task *task"
|
2009-08-17 09:01:20 +00:00
|
|
|
.Ft int
|
|
|
|
.Fn taskqueue_member "struct taskqueue *queue" "struct thread *td"
|
2001-12-26 23:14:04 +00:00
|
|
|
.Fn TASK_INIT "struct task *task" "int priority" "task_fn_t *func" "void *context"
|
2000-05-28 16:53:50 +00:00
|
|
|
.Fn TASKQUEUE_DECLARE "name"
|
2001-12-26 23:14:04 +00:00
|
|
|
.Fn TASKQUEUE_DEFINE "name" "taskqueue_enqueue_fn enqueue" "void *context" "init"
|
2008-06-13 19:35:17 +00:00
|
|
|
.Fn TASKQUEUE_FAST_DEFINE "name" "taskqueue_enqueue_fn enqueue" "void *context" "init"
|
2004-08-08 02:37:22 +00:00
|
|
|
.Fn TASKQUEUE_DEFINE_THREAD "name"
|
2008-06-13 19:35:17 +00:00
|
|
|
.Fn TASKQUEUE_FAST_DEFINE_THREAD "name"
|
2000-05-28 16:53:50 +00:00
|
|
|
.Sh DESCRIPTION
|
|
|
|
These functions provide a simple interface for asynchronous execution
|
|
|
|
of code.
|
|
|
|
.Pp
|
|
|
|
The function
|
|
|
|
.Fn taskqueue_create
|
|
|
|
is used to create new queues.
|
|
|
|
The arguments to
|
|
|
|
.Fn taskqueue_create
|
2005-05-01 02:12:44 +00:00
|
|
|
include a name that should be unique,
|
2000-05-28 16:53:50 +00:00
|
|
|
a set of
|
|
|
|
.Xr malloc 9
|
2005-05-01 02:12:44 +00:00
|
|
|
flags that specify whether the call to
|
2000-05-28 16:53:50 +00:00
|
|
|
.Fn malloc
|
2005-05-01 02:12:44 +00:00
|
|
|
is allowed to sleep,
|
|
|
|
a function that is called from
|
2000-05-28 16:53:50 +00:00
|
|
|
.Fn taskqueue_enqueue
|
2005-05-01 02:12:44 +00:00
|
|
|
when a task is added to the queue,
|
|
|
|
and a pointer to the memory location where the identity of the
|
|
|
|
thread that services the queue is recorded.
|
2000-05-28 16:53:50 +00:00
|
|
|
.\" XXX The rest of the sentence gets lots in relation to the first part.
|
2005-05-01 02:12:44 +00:00
|
|
|
The function called from
|
|
|
|
.Fn taskqueue_enqueue
|
|
|
|
must arrange for the queue to be processed
|
2000-05-28 16:53:50 +00:00
|
|
|
(for instance by scheduling a software interrupt or waking a kernel
|
|
|
|
thread).
|
2005-05-01 02:12:44 +00:00
|
|
|
The memory location where the thread identity is recorded is used
|
|
|
|
to signal the service thread(s) to terminate--when this value is set to
|
|
|
|
zero and the thread is signaled it will terminate.
|
2008-06-13 19:35:17 +00:00
|
|
|
If the queue is intended for use in fast interrupt handlers
|
|
|
|
.Fn taskqueue_create_fast
|
|
|
|
should be used in place of
|
|
|
|
.Fn taskqueue_create .
|
2000-05-28 16:53:50 +00:00
|
|
|
.Pp
|
|
|
|
The function
|
|
|
|
.Fn taskqueue_free
|
|
|
|
should be used to remove the queue from the global list of queues
|
|
|
|
and free the memory used by the queue.
|
2005-05-01 02:12:44 +00:00
|
|
|
Any tasks that are on the queue will be executed at this time after
|
|
|
|
which the thread servicing the queue will be signaled that it should exit.
|
2000-05-28 16:53:50 +00:00
|
|
|
.Pp
|
|
|
|
The system maintains a list of all queues which can be searched using
|
|
|
|
.Fn taskqueue_find .
|
|
|
|
The first queue whose name matches is returned, otherwise
|
|
|
|
.Dv NULL .
|
|
|
|
.Pp
|
|
|
|
To add a task to the list of tasks queued on a taskqueue, call
|
|
|
|
.Fn taskqueue_enqueue
|
|
|
|
with pointers to the queue and task.
|
|
|
|
If the task's
|
|
|
|
.Va ta_pending
|
|
|
|
field is non-zero,
|
|
|
|
then it is simply incremented to reflect the number of times the task
|
|
|
|
was enqueued.
|
|
|
|
Otherwise,
|
|
|
|
the task is added to the list before the first task which has a lower
|
|
|
|
.Va ta_priority
|
|
|
|
value or at the end of the list if no tasks have a lower priority.
|
|
|
|
Enqueueing a task does not perform any memory allocation which makes
|
|
|
|
it suitable for calling from an interrupt handler.
|
|
|
|
This function will return
|
2000-11-22 16:11:48 +00:00
|
|
|
.Er EPIPE
|
2000-05-28 16:53:50 +00:00
|
|
|
if the queue is being freed.
|
|
|
|
.Pp
|
2004-01-02 07:23:40 +00:00
|
|
|
The function
|
|
|
|
.Fn taskqueue_enqueue_fast
|
|
|
|
should be used in place of
|
|
|
|
.Fn taskqueue_enqueue
|
|
|
|
when the enqueuing must happen from a fast interrupt handler.
|
|
|
|
This method uses spin locks to avoid the possibility of sleeping in the fast
|
|
|
|
interrupt context.
|
|
|
|
.Pp
|
2000-05-28 16:53:50 +00:00
|
|
|
To execute all the tasks on a queue,
|
|
|
|
call
|
2005-04-19 16:23:00 +00:00
|
|
|
.Fn taskqueue_run
|
|
|
|
or
|
|
|
|
.Fn taskqueue_run_fast
|
|
|
|
depending on the flavour of the queue.
|
2000-05-28 16:53:50 +00:00
|
|
|
When a task is executed,
|
|
|
|
first it is removed from the queue,
|
|
|
|
the value of
|
|
|
|
.Va ta_pending
|
|
|
|
is recorded and then the field is zeroed.
|
|
|
|
The function
|
|
|
|
.Va ta_func
|
|
|
|
from the task structure is called with the value of the field
|
|
|
|
.Va ta_context
|
|
|
|
as its first argument
|
|
|
|
and the value of
|
|
|
|
.Va ta_pending
|
|
|
|
as its second argument.
|
2007-07-09 06:24:10 +00:00
|
|
|
After the function
|
|
|
|
.Va ta_func
|
|
|
|
returns,
|
|
|
|
.Xr wakeup 9
|
|
|
|
is called on the task pointer passed to
|
|
|
|
.Fn taskqueue_enqueue .
|
2000-05-28 16:53:50 +00:00
|
|
|
.Pp
|
2005-06-15 13:31:23 +00:00
|
|
|
The
|
2005-05-19 18:31:42 +00:00
|
|
|
.Fn taskqueue_drain
|
|
|
|
function is used to wait for the task to finish.
|
|
|
|
There is no guarantee that the task will not be
|
|
|
|
enqueued after call to
|
|
|
|
.Fn taskqueue_drain .
|
|
|
|
.Pp
|
2009-08-17 09:01:20 +00:00
|
|
|
The
|
|
|
|
.Fn taskqueue_member
|
|
|
|
function returns
|
|
|
|
.No 1
|
2009-08-17 10:20:22 +00:00
|
|
|
if the given thread
|
2009-08-17 09:01:20 +00:00
|
|
|
.Fa td
|
|
|
|
is part of the given taskqeueue
|
|
|
|
.Fa queue
|
|
|
|
and
|
|
|
|
.No 0
|
|
|
|
otherwise.
|
|
|
|
.Pp
|
2000-05-28 16:53:50 +00:00
|
|
|
A convenience macro,
|
|
|
|
.Fn TASK_INIT "task" "priority" "func" "context"
|
|
|
|
is provided to initialise a
|
|
|
|
.Va task
|
|
|
|
structure.
|
|
|
|
The values of
|
|
|
|
.Va priority ,
|
|
|
|
.Va func ,
|
|
|
|
and
|
|
|
|
.Va context
|
|
|
|
are simply copied into the task structure fields and the
|
|
|
|
.Va ta_pending
|
|
|
|
field is cleared.
|
|
|
|
.Pp
|
2008-06-13 19:35:17 +00:00
|
|
|
Five macros
|
2004-08-08 02:37:22 +00:00
|
|
|
.Fn TASKQUEUE_DECLARE "name" ,
|
|
|
|
.Fn TASKQUEUE_DEFINE "name" "enqueue" "context" "init" ,
|
2008-06-13 19:35:17 +00:00
|
|
|
.Fn TASKQUEUE_FAST_DEFINE "name" "enqueue" "context" "init" ,
|
2000-05-28 16:53:50 +00:00
|
|
|
and
|
2004-08-08 02:37:22 +00:00
|
|
|
.Fn TASKQUEUE_DEFINE_THREAD "name"
|
2008-06-13 19:35:17 +00:00
|
|
|
.Fn TASKQUEUE_FAST_DEFINE_THREAD "name"
|
2004-08-08 02:37:22 +00:00
|
|
|
are used to declare a reference to a global queue, to define the
|
2005-01-12 21:48:25 +00:00
|
|
|
implementation of the queue, and declare a queue that uses its own thread.
|
2000-05-28 16:53:50 +00:00
|
|
|
The
|
|
|
|
.Fn TASKQUEUE_DEFINE
|
|
|
|
macro arranges to call
|
|
|
|
.Fn taskqueue_create
|
|
|
|
with the values of its
|
|
|
|
.Va name ,
|
|
|
|
.Va enqueue
|
|
|
|
and
|
|
|
|
.Va context
|
|
|
|
arguments during system initialisation.
|
|
|
|
After calling
|
|
|
|
.Fn taskqueue_create ,
|
|
|
|
the
|
|
|
|
.Va init
|
|
|
|
argument to the macro is executed as a C statement,
|
|
|
|
allowing any further initialisation to be performed
|
|
|
|
(such as registering an interrupt handler etc.)
|
|
|
|
.Pp
|
2004-08-08 02:37:22 +00:00
|
|
|
The
|
|
|
|
.Fn TASKQUEUE_DEFINE_THREAD
|
2005-01-12 21:48:25 +00:00
|
|
|
macro defines a new taskqueue with its own kernel thread to serve tasks.
|
|
|
|
The variable
|
2004-08-08 02:37:22 +00:00
|
|
|
.Vt struct taskqueue *taskqueue_name
|
|
|
|
is used to enqueue tasks onto the queue.
|
2008-06-13 19:35:17 +00:00
|
|
|
.Pp
|
|
|
|
.Fn TASKQUEUE_FAST_DEFINE
|
|
|
|
and
|
|
|
|
.Fn TASKQUEUE_FAST_DEFINE_THREAD
|
|
|
|
act just like
|
|
|
|
.Fn TASKQUEUE_DEFINE
|
|
|
|
and
|
|
|
|
.Fn TASKQUEUE_DEFINE_THREAD
|
|
|
|
respectively but taskqueue is created with
|
|
|
|
.Fn taskqueue_create_fast .
|
2005-04-19 16:23:00 +00:00
|
|
|
.Ss Predefined Task Queues
|
|
|
|
The system provides four global taskqueues,
|
|
|
|
.Va taskqueue_fast ,
|
2000-05-28 16:53:50 +00:00
|
|
|
.Va taskqueue_swi ,
|
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
|
|
|
.Va taskqueue_swi_giant ,
|
2004-07-02 19:07:33 +00:00
|
|
|
and
|
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
|
|
|
.Va taskqueue_thread .
|
2005-04-19 16:23:00 +00:00
|
|
|
The
|
|
|
|
.Va taskqueue_fast
|
|
|
|
queue is for swi handlers dispatched from fast interrupt handlers,
|
|
|
|
where sleep mutexes cannot be used.
|
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
|
|
|
The swi taskqueues are run via a software interrupt mechanism.
|
2005-04-19 16:23:00 +00:00
|
|
|
The
|
|
|
|
.Va taskqueue_swi
|
|
|
|
queue runs without the protection of the
|
|
|
|
.Va Giant
|
|
|
|
kernel lock, and the
|
|
|
|
.Va taskqueue_swi_giant
|
|
|
|
queue runs with the protection of the
|
|
|
|
.Va Giant
|
|
|
|
kernel lock.
|
|
|
|
The thread taskqueue
|
|
|
|
.Va taskqueue_thread
|
|
|
|
runs in a kernel thread context, and tasks run from this thread do
|
|
|
|
not run under the
|
|
|
|
.Va Giant
|
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
|
|
|
kernel lock.
|
2005-04-19 16:23:00 +00:00
|
|
|
If the caller wants to run under
|
|
|
|
.Va Giant ,
|
|
|
|
he should explicitly acquire and release
|
|
|
|
.Va Giant
|
|
|
|
in his taskqueue handler routine.
|
2004-06-16 08:33:57 +00:00
|
|
|
.Pp
|
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
|
|
|
To use these queues,
|
2000-05-28 16:53:50 +00:00
|
|
|
call
|
|
|
|
.Fn taskqueue_enqueue
|
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
|
|
|
with the value of the global taskqueue variable for the queue you wish to
|
2005-01-12 21:48:25 +00:00
|
|
|
use
|
|
|
|
.Va ( taskqueue_swi ,
|
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
|
|
|
.Va taskqueue_swi_giant ,
|
|
|
|
or
|
2005-01-12 21:48:25 +00:00
|
|
|
.Va taskqueue_thread ) .
|
2005-04-19 16:23:00 +00:00
|
|
|
Use
|
|
|
|
.Fn taskqueue_enqueue_fast
|
|
|
|
for the global taskqueue variable
|
|
|
|
.Va taskqueue_fast .
|
2000-05-28 16:53:50 +00:00
|
|
|
.Pp
|
2003-09-03 05:35:37 +00:00
|
|
|
The software interrupt queues can be used,
|
2000-05-28 16:53:50 +00:00
|
|
|
for instance, for implementing interrupt handlers which must perform a
|
|
|
|
significant amount of processing in the handler.
|
|
|
|
The hardware interrupt handler would perform minimal processing of the
|
|
|
|
interrupt and then enqueue a task to finish the work.
|
|
|
|
This reduces to a minimum
|
|
|
|
the amount of time spent with interrupts disabled.
|
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
|
|
|
.Pp
|
|
|
|
The thread queue can be used, for instance, by interrupt level routines
|
|
|
|
that need to call kernel functions that do things that can only be done
|
|
|
|
from a thread context.
|
|
|
|
(e.g., call malloc with the M_WAITOK flag.)
|
2005-05-01 02:12:44 +00:00
|
|
|
.Pp
|
|
|
|
Note that tasks queued on shared taskqueues such as
|
|
|
|
.Va taskqueue_swi
|
|
|
|
may be delayed an indeterminate amount of time before execution.
|
|
|
|
If queueing delays cannot be tolerated then a private taskqueue should
|
|
|
|
be created with a dedicated processing thread.
|
2005-04-15 14:46:59 +00:00
|
|
|
.Sh SEE ALSO
|
|
|
|
.Xr ithread 9 ,
|
|
|
|
.Xr kthread 9 ,
|
|
|
|
.Xr swi 9
|
2000-05-28 16:53:50 +00:00
|
|
|
.Sh HISTORY
|
|
|
|
This interface first appeared in
|
|
|
|
.Fx 5.0 .
|
|
|
|
There is a similar facility called tqueue in the Linux kernel.
|
|
|
|
.Sh AUTHORS
|
2005-06-28 20:15:19 +00:00
|
|
|
This manual page was written by
|
2000-05-28 16:53:50 +00:00
|
|
|
.An Doug Rabson .
|