#
4af83c8c |
| 18-Jul-2008 |
Kip Macy <kmacy@FreeBSD.org> |
import vendor fixes to cxgb
|
#
03c7442d |
| 11-Apr-2008 |
John Baldwin <jhb@FreeBSD.org> |
Use kthread_exit() to terminate a taskqueue thread rather than kproc_exit() now that the taskqueue threads are kthreads rather than kprocs.
Reported by: kris
|
#
175611b6 |
| 08-Apr-2008 |
Sam Leffler <sam@FreeBSD.org> |
change taskqueue_start_threads to create threads instead of proc's
Reviewed by: jhb
|
#
478cfc73 |
| 25-Mar-2008 |
Scott Long <scottl@FreeBSD.org> |
Implement taskqueue_block() and taskqueue_unblock(). These functions allow the owner of a queue to block and unblock execution of the tasks in the queue while allowing tasks to continue to be added
Implement taskqueue_block() and taskqueue_unblock(). These functions allow the owner of a queue to block and unblock execution of the tasks in the queue while allowing tasks to continue to be added queue. Combining this with taskqueue_drain() allows a queue to be safely disabled. The unblock function may run (or schedule to run) the queue when it is called, just as calling taskqueue_enqueue() would.
Reviewed by: jhb, sam
show more ...
|
Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0 |
|
#
3745c395 |
| 21-Oct-2007 |
Julian Elischer <julian@FreeBSD.org> |
Rename the kthread_xxx (e.g. kthread_create()) calls to kproc_xxx as they actually make whole processes. Thos makes way for us to add REAL kthread_create() and friends that actually make theads. it t
Rename the kthread_xxx (e.g. kthread_create()) calls to kproc_xxx as they actually make whole processes. Thos makes way for us to add REAL kthread_create() and friends that actually make theads. it turns out that most of these calls actually end up being moved back to the thread version when it's added. but we need to make this cosmetic change first.
I'd LOVE to do this rename in 7.0 so that we can eventually MFC the new kthread_xxx() calls.
show more ...
|
#
982d11f8 |
| 05-Jun-2007 |
Jeff Roberson <jeff@FreeBSD.org> |
Commit 14/14 of sched_lock decomposition. - Use thread_lock() rather than sched_lock for per-thread scheduling sychronization. - Use the per-process spinlock rather than the sched_lock for per-p
Commit 14/14 of sched_lock decomposition. - Use thread_lock() rather than sched_lock for per-thread scheduling sychronization. - Use the per-process spinlock rather than the sched_lock for per-process scheduling synchronization.
Tested by: kris, current@ Tested on: i386, amd64, ULE, 4BSD, libthr, libkse, PREEMPTION, etc. Discussed with: kris, attilio, kmacy, jhb, julian, bde (small parts each)
show more ...
|
#
f0393f06 |
| 23-Jan-2007 |
Jeff Roberson <jeff@FreeBSD.org> |
- Remove setrunqueue and replace it with direct calls to sched_add(). setrunqueue() was mostly empty. The few asserts and thread state setting were moved to the individual schedulers. sched_a
- Remove setrunqueue and replace it with direct calls to sched_add(). setrunqueue() was mostly empty. The few asserts and thread state setting were moved to the individual schedulers. sched_add() was chosen to displace it for naming consistency reasons. - Remove adjustrunqueue, it was 4 lines of code that was ifdef'd to be different on all three schedulers where it was only called in one place each. - Remove the long ifdef'd out remrunqueue code. - Remove the now redundant ts_state. Inspect the thread state directly. - Don't set TSF_* flags from kern_switch.c, we were only doing this to support a feature in one scheduler. - Change sched_choose() to return a thread rather than a td_sched. Also, rely on the schedulers to return the idlethread. This simplifies the logic in choosethread(). Aside from the run queue links kern_switch.c mostly does not care about the contents of td_sched.
Discussed with: julian
- Move the idle thread loop into the per scheduler area. ULE wants to do something different from the other schedulers.
Suggested by: jhb
Tested on: x86/amd64 sched_{4BSD, ULE, CORE}.
show more ...
|
Revision tags: release/6.2.0_cvs, release/6.2.0 |
|
#
75b773ae |
| 25-May-2006 |
Sam Leffler <sam@FreeBSD.org> |
When starting up threads in taskqueue_start_threads create them stopped before adjusting their priority and setting them on the run q so they cannot race for resources (pointed out by njl).
While he
When starting up threads in taskqueue_start_threads create them stopped before adjusting their priority and setting them on the run q so they cannot race for resources (pointed out by njl).
While here add a console printf on thread create fails; otherwise noone may notice (e.g. return value is always 0 and caller has no way to verify).
Reviewed by: jhb, scottl MFC after: 2 weeks
show more ...
|
Revision tags: release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0 |
|
#
0f180a7c |
| 17-Apr-2006 |
John Baldwin <jhb@FreeBSD.org> |
Change msleep() and tsleep() to not alter the calling thread's priority if the specified priority is zero. This avoids a race where the calling thread could read a snapshot of it's current priority,
Change msleep() and tsleep() to not alter the calling thread's priority if the specified priority is zero. This avoids a race where the calling thread could read a snapshot of it's current priority, then a different thread could change the first thread's priority, then the original thread would call sched_prio() inside msleep() undoing the change made by the second thread. I used a priority of zero as no thread that calls msleep() or tsleep() should be specifying a priority of zero anyway.
The various places that passed 'curthread->td_priority' or some variant as the priority now pass 0.
show more ...
|
#
00537061 |
| 31-Mar-2006 |
Sam Leffler <sam@FreeBSD.org> |
fixup error handling in taskqueue_start_threads: check for kthread_create failing, print a message when we fail for some reason as most callers do not check the return value (e.g. 'cuz they're called
fixup error handling in taskqueue_start_threads: check for kthread_create failing, print a message when we fail for some reason as most callers do not check the return value (e.g. 'cuz they're called from SYSINIT)
Reviewed by: scottl MFC after: 1 week
show more ...
|
#
0f92108d |
| 14-Jan-2006 |
Scott Long <scottl@FreeBSD.org> |
Add the following to the taskqueue api:
taskqueue_start_threads(struct taskqueue **, int count, int pri, const char *name, ...);
This allows the creation of 1 or more threads that will service a
Add the following to the taskqueue api:
taskqueue_start_threads(struct taskqueue **, int count, int pri, const char *name, ...);
This allows the creation of 1 or more threads that will service a single taskqueue. Also rework the taskqueue_create() API to remove the API change that was introduced a while back. Creating a taskqueue doesn't rely on the presence of a process structure, and the proc mechanics are much better encapsulated in taskqueue_start_threads(). Also clean up the taskqueue_terminate() and taskqueue_free() functions to safely drain pending tasks and remove all associated threads.
The TASKQUEUE_DEFINE and TASKQUEUE_DEFINE_THREAD macros have been changed to use the new API, but drivers compiled against the old definitions will still work. Thus, recompiling drivers is not a strict requirement.
show more ...
|
#
1c3a3b0b |
| 11-Jan-2006 |
Scott Long <scottl@FreeBSD.org> |
The interlock in taskqueue_terminate() is completely wrong for taskqueues that use spinlocks. Remove it for now.
|
#
9df1a6dd |
| 10-Jan-2006 |
Scott Long <scottl@FreeBSD.org> |
Add functions and macros and refactor code to make it easier to manage fast taskqueues. The following have been added:
TASKQUEUE_FAST_DEFINE() - create a global task queue. an arbitrary executi
Add functions and macros and refactor code to make it easier to manage fast taskqueues. The following have been added:
TASKQUEUE_FAST_DEFINE() - create a global task queue. an arbitrary execution context. TASKQUEUE_FAST_DEFINE_THREAD() - create a global taskqueue that uses a dedicated kthread. taskqueue_create_fast() - create a local/private taskqueue.
These are all complimentary of the standard taskqueue functions. They are primarily useful for fast interrupt handlers that can only use spinlock for synchronization.
I personally think that the taskqueue API is starting to get too narrow and hairy, but fixing it will require a major redesign on the API. Such a redesign would be good but would break compatibility with FreeBSD 6.x, so it really isn't desirable at this time.
Submitted by: sam
show more ...
|
#
d2a401cb |
| 23-Dec-2005 |
Scott Long <scottl@FreeBSD.org> |
Create the taskqueue_fast handler with INTR_MPSAFE so that it doesn't run with Giant.
MFC After: 3 days
|
Revision tags: release/6.0.0_cvs, release/6.0.0 |
|
#
6caf758e |
| 25-Oct-2005 |
John Baldwin <jhb@FreeBSD.org> |
Use shorter names for the Giant and fast taskqueues so that their names actually fit.
|
#
8d2a5b8c |
| 24-Oct-2005 |
John Baldwin <jhb@FreeBSD.org> |
Revert previous change to this file. I accidentally committed while fixing spelling in a comment.
|
#
971d0ad8 |
| 24-Oct-2005 |
John Baldwin <jhb@FreeBSD.org> |
Spell hierarchy correctly in comments.
Submitted by: Wojciech A. Koszek dunstan at freebsd dot czest dot pl
|
Revision tags: release/5.4.0_cvs, release/5.4.0 |
|
#
52bc746a |
| 01-May-2005 |
Sam Leffler <sam@FreeBSD.org> |
o enable shutdown of taskqueue threads; the thread servicing the queue checks a new entry in the taskqueue struct each time it wakes up to see if it should terminate o adjust TASKQUEUE_DEFINE_THR
o enable shutdown of taskqueue threads; the thread servicing the queue checks a new entry in the taskqueue struct each time it wakes up to see if it should terminate o adjust TASKQUEUE_DEFINE_THREAD & co. to record the thread/proc identity for the shutdown rendezvous o replace wakeup after adding a task to a queue with wakeup_one; this helps queues where multiple threads are used to service tasks (e.g. acpi) o remove NULL check of tq_enqueue method; it should never be NULL
Reviewed by: dfr, njl
show more ...
|
#
f4581151 |
| 24-Apr-2005 |
Sam Leffler <sam@FreeBSD.org> |
o eliminate modification of task structures after their run to avoid modify-after-free races when the task structure is malloc'd o shrink task structure by removing ta_flags (no longer needed with
o eliminate modification of task structures after their run to avoid modify-after-free races when the task structure is malloc'd o shrink task structure by removing ta_flags (no longer needed with avoid fix) and combining ta_pending and ta_priority
Reviewed by: dwhite, dfr MFC after: 4 days
show more ...
|
Revision tags: release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0 |
|
#
14889b42 |
| 05-Oct-2004 |
Warner Losh <imp@FreeBSD.org> |
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.
|
#
227559d1 |
| 08-Aug-2004 |
John-Mark Gurney <jmg@FreeBSD.org> |
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 the
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.
show more ...
|
#
bd83e879 |
| 28-Jun-2004 |
John Baldwin <jhb@FreeBSD.org> |
- Execute all of the tasks on the taskqueue during taskqueue_free() after the queue has been removed from the global taskqueue_queues list. This removes the need for the draining queue hack. - A
- Execute all of the tasks on the taskqueue during taskqueue_free() after the queue has been removed from the global taskqueue_queues list. This removes the need for the draining queue hack. - Allow taskqueue_run() to be called with the taskqueue mutex held. It can still be called without the lock for API compatiblity. In that case it will acquire the lock internally. - Don't lock the individual queue mutex in taskqueue_find() until after the strcmp as the global queues mutex is sufficient for the strcmp. - Simplify taskqueue_thread_loop() now that it can hold the lock across taskqueue_run().
Submitted by: bde (mostly)
show more ...
|
Revision tags: release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1 |
|
#
712f57d8 |
| 19-Feb-2004 |
John Baldwin <jhb@FreeBSD.org> |
Tidy up the thread taskqueue implementation and close a lost wakeup race. Instead of creating a mutex that we msleep on but don't actually lock when doing the corresponding wakeup(), in the kthread,
Tidy up the thread taskqueue implementation and close a lost wakeup race. Instead of creating a mutex that we msleep on but don't actually lock when doing the corresponding wakeup(), in the kthread, lock the mutex associated with our taskqueue and msleep while the queue is empty. Assert that the queue is locked when the callback function is called to wake the kthread.
show more ...
|
Revision tags: release/5.2.0_cvs, release/5.2.0 |
|
#
eb5b0e05 |
| 17-Dec-2003 |
John Baldwin <jhb@FreeBSD.org> |
Various style fixes.
Submitted by: bde (mostly, if not all)
|
#
cd3c61b9 |
| 10-Nov-2003 |
Alfred Perlstein <alfred@FreeBSD.org> |
Fix a bug where the taskqueue kproc was being parented by init because RFNOWAIT was being passed to kproc_create.
The result was that shutdown took quite a bit longer because this errant "child" wou
Fix a bug where the taskqueue kproc was being parented by init because RFNOWAIT was being passed to kproc_create.
The result was that shutdown took quite a bit longer because this errant "child" would not respond to termination signals from init at system shutdown.
RFNOWAIT dissassociates itself from the caller by attaching to init as a parent proc. We could have had the taskqueue proc listen for SIGKILL, but being able to SIGKILL a potentially critical system process doesn't seem like a good idea.
show more ...
|