c390936c21
sys/kern/subr_workqueue.c: revision 1.40 sys/kern/subr_workqueue.c: revision 1.41 sys/kern/subr_workqueue.c: revision 1.42 sys/kern/subr_workqueue.c: revision 1.43 sys/kern/subr_workqueue.c: revision 1.44 sys/kern/subr_workqueue.c: revision 1.45 sys/kern/subr_workqueue.c: revision 1.46 tests/rump/kernspace/workqueue.c: revision 1.7 sys/kern/subr_workqueue.c: revision 1.47 tests/rump/kernspace/workqueue.c: revision 1.8 tests/rump/kernspace/workqueue.c: revision 1.9 tests/rump/rumpkern/t_workqueue.c: revision 1.3 tests/rump/rumpkern/t_workqueue.c: revision 1.4 tests/rump/kernspace/kernspace.h: revision 1.9 tests/rump/rumpkern/Makefile: revision 1.20 sys/kern/subr_workqueue.c: revision 1.39 share/man/man9/workqueue.9: revision 1.15 (all via patch) workqueue: Lift unnecessary restriction on workqueue_wait. Allow multiple concurrent waits at a time, and allow enqueueing work at the same time (as long as it's not the work we're waiting for). This way multiple users can use a shared global workqueue and safely wait for individual work items concurrently, while the workqueue is still in use for other items (e.g., wg(4) peers). This has the side effect of taking away a diagnostic measure, but I think allowing the diagnostic's false positives instead of rejecting them is worth it. We could cheaply add it back with some false negatives if it's important. workqueue(9): workqueue_wait and workqueue_destroy may sleep. But might not, so assert sleepable up front. workqueue(9): Sprinkle dtrace probes. tests/rump/rumpkern: Use PROGDPLIBS, not explicit -L/-l. This way we relink the t_* test programs whenever changes under tests/rump/kernspace change libkernspace.a. workqueue(9) tests: Nix trailing whitespace. workqueue(9) tests: Destroy struct work immediately on entry. workqueue(9) tests: Add test for PR kern/57574. workqueue(9): Avoid touching running work items in workqueue_wait. As soon as the workqueue function has called, it is forbidden to touch the struct work passed to it -- the function might free or reuse the data structure it is embedded in. So workqueue_wait is forbidden to search the queue for the batch of running work items. Instead, use a generation number which is odd while the thread is processing a batch of work and even when not. There's still a small optimization available with the struct work pointer to wait for: if we find the work item in one of the per-CPU _pending_ queues, then after we wait for a batch of work to complete on that CPU, we don't need to wait for work on any other CPUs. PR kern/57574 workqueue(9): Sprinkle dtrace probes for workqueue_wait edge cases. Let's make it easy to find out whether these are hit. workqueue(9): Stop violating queue(3) internals. workqueue(9): Avoid unnecessary mutex_exit/enter cycle each loop. workqueue(9): Sort includes. No functional change intended. workqueue(9): Factor out wq->wq_flags & WQ_FPU in workqueue_worker. No functional change intended. Makes it clearer that s is initialized when used. |
||
---|---|---|
.. | ||
bin | ||
crypto | ||
dev | ||
fs | ||
games | ||
include | ||
ipf | ||
kernel | ||
lib | ||
libexec | ||
modules | ||
net | ||
rump | ||
sbin | ||
share | ||
sys | ||
usr.bin | ||
usr.sbin | ||
Makefile | ||
Makefile.inc | ||
README | ||
h_macros.h |
README
$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $ When adding new tests, please try to follow the following conventions. 1. For library routines, including system calls, the directory structure of the tests should follow the directory structure of the real source tree. For instance, interfaces available via the C library should follow: src/lib/libc/gen -> src/tests/lib/libc/gen src/lib/libc/sys -> src/tests/lib/libc/sys ... 2. Equivalently, all tests for userland utilities should try to follow their location in the source tree. If this can not be satisfied, the tests for a utility should be located under the directory to which the utility is installed. Thus, a test for env(1) should go to src/tests/usr.bin/env. Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump, even though the source code for the program is located under src/external. 3. Otherwise use your own discretion.