freebsd-nq/share/man/man9/taskqueue.9

505 lines
15 KiB
Groff
Raw Normal View History

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$
.\"
.Dd July 30, 2017
2000-05-28 16:53:50 +00:00
.Dt TASKQUEUE 9
.Os
.Sh NAME
.Nm taskqueue
.Nd asynchronous task execution
.Sh SYNOPSIS
.In sys/param.h
.In sys/kernel.h
.In sys/malloc.h
.In sys/queue.h
.In sys/taskqueue.h
2000-05-28 16:53:50 +00:00
.Bd -literal
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 */
task_fn_t ta_func; /* task handler */
2000-05-28 16:53:50 +00:00
void *ta_context; /* argument for handler */
};
enum taskqueue_callback_type {
TASKQUEUE_CALLBACK_TYPE_INIT,
TASKQUEUE_CALLBACK_TYPE_SHUTDOWN,
};
typedef void (*taskqueue_callback_fn)(void *context);
struct timeout_task;
2000-05-28 16:53:50 +00:00
.Ed
.Ft struct taskqueue *
.Fn taskqueue_create "const char *name" "int mflags" "taskqueue_enqueue_fn enqueue" "void *context"
.Ft struct taskqueue *
.Fn taskqueue_create_fast "const char *name" "int mflags" "taskqueue_enqueue_fn enqueue" "void *context"
.Ft int
.Fn taskqueue_start_threads "struct taskqueue **tqp" "int count" "int pri" "const char *name" "..."
.Ft int
.Fo taskqueue_start_threads_pinned
.Fa "struct taskqueue **tqp" "int count" "int pri" "int cpu_id"
.Fa "const char *name" "..."
.Fc
.Ft void
.Fn taskqueue_set_callback "struct taskqueue *queue" "enum taskqueue_callback_type cb_type" "taskqueue_callback_fn callback" "void *context"
2000-05-28 16:53:50 +00:00
.Ft void
.Fn taskqueue_free "struct taskqueue *queue"
.Ft int
.Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task"
2004-01-02 07:23:40 +00:00
.Ft int
.Fn taskqueue_enqueue_timeout "struct taskqueue *queue" "struct timeout_task *timeout_task" "int ticks"
.Ft int
.Fn taskqueue_enqueue_timeout_sbt "struct taskqueue *queue" "struct timeout_task *timeout_task" "sbintime_t sbt" "sbintime_t pr" "int flags"
.Ft int
.Fn taskqueue_cancel "struct taskqueue *queue" "struct task *task" "u_int *pendp"
.Ft int
.Fn taskqueue_cancel_timeout "struct taskqueue *queue" "struct timeout_task *timeout_task" "u_int *pendp"
2000-05-28 16:53:50 +00:00
.Ft void
2005-05-19 18:31:42 +00:00
.Fn taskqueue_drain "struct taskqueue *queue" "struct task *task"
.Ft void
.Fn taskqueue_drain_timeout "struct taskqueue *queue" "struct timeout_task *timeout_task"
.Ft void
.Fn taskqueue_drain_all "struct taskqueue *queue"
.Ft void
.Fn taskqueue_block "struct taskqueue *queue"
.Ft void
.Fn taskqueue_unblock "struct taskqueue *queue"
.Ft int
.Fn taskqueue_member "struct taskqueue *queue" "struct thread *td"
.Ft void
.Fn taskqueue_run "struct taskqueue *queue"
.Fn TASK_INIT "struct task *task" "int priority" "task_fn_t func" "void *context"
.Fn TASK_INITIALIZER "int priority" "task_fn_t func" "void *context"
2000-05-28 16:53:50 +00:00
.Fn TASKQUEUE_DECLARE "name"
.Fn TASKQUEUE_DEFINE "name" "taskqueue_enqueue_fn enqueue" "void *context" "init"
.Fn TASKQUEUE_FAST_DEFINE "name" "taskqueue_enqueue_fn enqueue" "void *context" "init"
.Fn TASKQUEUE_DEFINE_THREAD "name"
.Fn TASKQUEUE_FAST_DEFINE_THREAD "name"
.Fn TIMEOUT_TASK_INIT "struct taskqueue *queue" "struct timeout_task *timeout_task" "int priority" "task_fn_t func" "void *context"
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.
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 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
Once a taskqueue has been created, its threads should be started using
.Fn taskqueue_start_threads
or
.Fn taskqueue_start_threads_pinned .
.Fn taskqueue_start_threads_pinned
takes a
.Va cpu_id
argument which will cause the threads which are started for the taskqueue
to be pinned to run on the given CPU.
Callbacks may optionally be registered using
.Fn taskqueue_set_callback .
Currently, callbacks may be registered for the following purposes:
.Bl -tag -width TASKQUEUE_CALLBACK_TYPE_SHUTDOWN
.It Dv TASKQUEUE_CALLBACK_TYPE_INIT
This callback is called by every thread in the taskqueue, before it executes
any tasks.
This callback must be set before the taskqueue's threads are started.
.It Dv TASKQUEUE_CALLBACK_TYPE_SHUTDOWN
This callback is called by every thread in the taskqueue, after it executes
its last task.
This callback will always be called before the taskqueue structure is
reclaimed.
.El
.Pp
2000-05-28 16:53:50 +00:00
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, up to a cap of USHRT_MAX.
2000-05-28 16:53:50 +00:00
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
.Er EPIPE
2000-05-28 16:53:50 +00:00
if the queue is being freed.
.Pp
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.
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
The
.Fn taskqueue_enqueue_timeout
function is used to schedule the enqueue after the specified number of
.Va ticks .
The
.Fn taskqueue_enqueue_timeout_sbt
function provides finer control over the scheduling based on
.Va sbt ,
.Va pr ,
and
.Va flags ,
as detailed in
.Xr timeout 9 .
Only non-fast task queues can be used for
.Va timeout_task
scheduling.
If the
.Va ticks
argument is negative, the already scheduled enqueueing is not re-scheduled.
Otherwise, the task is scheduled for enqueueing in the future,
after the absolute value of
.Va ticks
is passed.
This function returns -1 if the task is being drained.
Otherwise, the number of pending calls is returned.
.Pp
The
.Fn taskqueue_cancel
function is used to cancel a task.
The
.Va ta_pending
count is cleared, and the old value returned in the reference
parameter
.Fa pendp ,
if it is
.Pf non- Dv NULL .
If the task is currently running,
.Dv EBUSY
is returned, otherwise 0.
To implement a blocking
.Fn taskqueue_cancel
that waits for a running task to finish, it could look like:
.Bd -literal -offset indent
while (taskqueue_cancel(tq, task, NULL) != 0)
taskqueue_drain(tq, task);
.Ed
.Pp
Note that, as with
.Fn taskqueue_drain ,
the caller is responsible for ensuring that the task is not re-enqueued
after being canceled.
.Pp
Similarly, the
.Fn taskqueue_cancel_timeout
function is used to cancel the scheduled task execution.
.Pp
The
2005-05-19 18:31:42 +00:00
.Fn taskqueue_drain
function is used to wait for the task to finish, and
the
.Fn taskqueue_drain_timeout
function is used to wait for the scheduled task to finish.
2005-05-19 18:31:42 +00:00
There is no guarantee that the task will not be
enqueued after call to
.Fn taskqueue_drain .
If the caller wants to put the task into a known state,
then before calling
.Fn taskqueue_drain
the caller should use out-of-band means to ensure that the task
would not be enqueued.
For example, if the task is enqueued by an interrupt filter, then
the interrupt could be disabled.
.Pp
The
.Fn taskqueue_drain_all
function is used to wait for all pending and running tasks that
are enqueued on the taskqueue to finish.
Tasks posted to the taskqueue after
.Fn taskqueue_drain_all
begins processing,
2015-06-18 16:29:11 +00:00
including pending enqueues scheduled by a previous call to
.Fn taskqueue_enqueue_timeout ,
do not extend the wait time of
.Fn taskqueue_drain_all
2015-06-18 16:29:11 +00:00
and may complete after
.Fn taskqueue_drain_all
returns.
.Pp
The
.Fn taskqueue_block
function blocks the taskqueue.
It prevents any enqueued but not running tasks from being executed.
Future calls to
.Fn taskqueue_enqueue
will enqueue tasks, but the tasks will not be run until
.Fn taskqueue_unblock
is called.
Please note that
.Fn taskqueue_block
does not wait for any currently running tasks to finish.
Thus, the
.Fn taskqueue_block
does not provide a guarantee that
.Fn taskqueue_run
is not running after
.Fn taskqueue_block
returns, but it does provide a guarantee that
.Fn taskqueue_run
will not be called again
until
.Fn taskqueue_unblock
is called.
If the caller requires a guarantee that
.Fn taskqueue_run
is not running, then this must be arranged by the caller.
Note that if
.Fn taskqueue_drain
is called on a task that is enqueued on a taskqueue that is blocked by
.Fn taskqueue_block ,
then
.Fn taskqueue_drain
can not return until the taskqueue is unblocked.
This can result in a deadlock if the thread blocked in
.Fn taskqueue_drain
is the thread that is supposed to call
.Fn taskqueue_unblock .
Thus, use of
.Fn taskqueue_drain
after
.Fn taskqueue_block
is discouraged, because the state of the task can not be known in advance.
The same caveat applies to
.Fn taskqueue_drain_all .
.Pp
The
.Fn taskqueue_unblock
function unblocks the previously blocked taskqueue.
All enqueued tasks can be run after this call.
2005-05-19 18:31:42 +00:00
.Pp
The
.Fn taskqueue_member
function returns
.No 1
if the given thread
.Fa td
2010-07-31 10:01:15 +00:00
is part of the given taskqueue
.Fa queue
and
.No 0
otherwise.
.Pp
The
.Fn taskqueue_run
function will run all pending tasks in the specified
.Fa queue .
Normally this function is only used internally.
.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
.Fn TASK_INITIALIZER
macro generates an initializer for a task structure.
A macro
.Fn TIMEOUT_TASK_INIT "queue" "timeout_task" "priority" "func" "context"
initializes the
.Va timeout_task
structure.
2000-05-28 16:53:50 +00:00
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
Five macros
.Fn TASKQUEUE_DECLARE "name" ,
.Fn TASKQUEUE_DEFINE "name" "enqueue" "context" "init" ,
.Fn TASKQUEUE_FAST_DEFINE "name" "enqueue" "context" "init" ,
2000-05-28 16:53:50 +00:00
and
.Fn TASKQUEUE_DEFINE_THREAD "name"
.Fn TASKQUEUE_FAST_DEFINE_THREAD "name"
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.).
2000-05-28 16:53:50 +00:00
.Pp
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
.Vt struct taskqueue *taskqueue_name
is used to enqueue tasks onto the queue.
.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 .
.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 .
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.
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.
If the caller wants to run under
.Va Giant ,
he should explicitly acquire and release
.Va Giant
in his taskqueue handler routine.
.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
use.
2000-05-28 16:53:50 +00:00
.Pp
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
.Xr timeout 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 work_queue in the Linux kernel.
2000-05-28 16:53:50 +00:00
.Sh AUTHORS
This manual page was written by
2000-05-28 16:53:50 +00:00
.An Doug Rabson .