|
Revision tags: release/12.2.0, release/11.4.0, release/12.1.0 |
|
| #
7e8be396 |
| 07-Jul-2019 |
Alexander Motin <[email protected]> |
MFC r349220: Add wakeup_any(), cheaper wakeup_one() for taskqueue(9).
wakeup_one() and underlying sleepq_signal() spend additional time trying to be fair, waking thread with highest priority, sleepi
MFC r349220: Add wakeup_any(), cheaper wakeup_one() for taskqueue(9).
wakeup_one() and underlying sleepq_signal() spend additional time trying to be fair, waking thread with highest priority, sleeping longest time. But in case of taskqueue there are many absolutely identical threads, and any fairness between them is quite pointless. It makes even worse, since round-robin wakeups not only make previous CPU affinity in scheduler quite useless, but also hide from user chance to see CPU bottlenecks, when sequential workload with one request at a time looks evenly distributed between multiple threads.
This change adds new SLEEPQ_UNFAIR flag to sleepq_signal(), making it wakeup thread that went to sleep last, but no longer in context switch (to avoid immediate spinning on the thread lock). On top of that new wakeup_any() function is added, equivalent to wakeup_one(), but setting the flag. On top of that taskqueue(9) is switchied to wakeup_any() to wakeup its threads.
As result, on 72-core Xeon v4 machine sequential ZFS write to 12 ZVOLs with 16KB block size spend 34% less time in wakeup_any() and descendants then it was spending in wakeup_one(), and total write throughput increased by ~10% with the same as before CPU usage.
show more ...
|
|
Revision tags: release/11.3.0, release/12.0.0 |
|
| #
852add40 |
| 28-Nov-2018 |
Mark Johnston <[email protected]> |
MFC r340730, r340731: Add taskqueue_quiesce(9) and use it to implement taskq_wait().
PR: 227784
|
|
Revision tags: release/11.2.0 |
|
| #
ac2fffa4 |
| 21-Jan-2018 |
Pedro F. Giffuni <[email protected]> |
Revert r327828, r327949, r327953, r328016-r328026, r328041: Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation
Revert r327828, r327949, r327953, r328016-r328026, r328041: Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation size attributes which put extra pressure on the compiler.
Given that most of these checks are superfluous we have to choose better where to use mallocarray(9). We still have more uses of mallocarray(9) but hopefully this is enough to bring swap usage to a reasonable level.
Reported by: wosch PR: 225197
show more ...
|
| #
a18a2290 |
| 15-Jan-2018 |
Pedro F. Giffuni <[email protected]> |
kern: make some use of mallocarray(9).
Focus on code where we are doing multiplications within malloc(9). None of these ire likely to overflow, however the change is still useful as some static chec
kern: make some use of mallocarray(9).
Focus on code where we are doing multiplications within malloc(9). None of these ire likely to overflow, however the change is still useful as some static checkers can benefit from the allocation attributes we use for mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good reason but I started doing the changes before r327796 and at that time it was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
show more ...
|
| #
8a36da99 |
| 27-Nov-2017 |
Pedro F. Giffuni <[email protected]> |
sys/kern: adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone
sys/kern: adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
|
Revision tags: release/10.4.0 |
|
| #
f37b7fc2 |
| 31-Jul-2017 |
Ian Lepore <[email protected]> |
Add taskqueue_enqueue_timeout_sbt(), because sometimes you want more control over the scheduling precision than 'ticks' can offer, and because sometimes you're already working with sbintime_t units a
Add taskqueue_enqueue_timeout_sbt(), because sometimes you want more control over the scheduling precision than 'ticks' can offer, and because sometimes you're already working with sbintime_t units and it's dumb to convert them to ticks just so they can get converted back to sbintime_t under the hood.
show more ...
|
|
Revision tags: release/11.1.0 |
|
| #
403f4a31 |
| 02-Mar-2017 |
Hans Petter Selasky <[email protected]> |
Implement taskqueue_poll_is_busy() for use by the LinuxKPI. Refer to comment above function for a detailed description.
Discussed with: kib @ MFC after: 1 week Sponsored by: Mellanox Technologies
|
| #
99eca1b2 |
| 29-Sep-2016 |
Hans Petter Selasky <[email protected]> |
While draining a timeout task prevent the taskqueue_enqueue_timeout() function from restarting the timer.
Commonly taskqueue_enqueue_timeout() is called from within the task function itself without
While draining a timeout task prevent the taskqueue_enqueue_timeout() function from restarting the timer.
Commonly taskqueue_enqueue_timeout() is called from within the task function itself without any checks for teardown. Then it can happen the timer stays active after the return of taskqueue_drain_timeout(), because the timeout and task is drained separately.
This patch factors out the teardown flag into the timeout task itself, allowing existing code to stay as-is instead of applying a teardown flag to each and every of the timeout task consumers.
Add assert to taskqueue_drain_timeout() which prevents parallel execution on the same timeout task.
Update manual page documenting the return value of taskqueue_enqueue_timeout().
Differential Revision: https://reviews.freebsd.org/D8012 Reviewed by: kib, trasz MFC after: 1 week
show more ...
|
|
Revision tags: release/11.0.1, release/11.0.0 |
|
| #
da2ded65 |
| 01-Sep-2016 |
Patrick Kelsey <[email protected]> |
_taskqueue_start_threads() now fails if it doesn't actually start any threads.
Reviewed by: jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D7701
|
| #
23ac9029 |
| 12-Aug-2016 |
Stephen Hurd <[email protected]> |
Update iflib to support more NIC designs
- Move group task queue into kern/subr_gtaskqueue.c - Change intr_enable to return an int so it can be detected if it's not implemented - Allow different T
Update iflib to support more NIC designs
- Move group task queue into kern/subr_gtaskqueue.c - Change intr_enable to return an int so it can be detected if it's not implemented - Allow different TX/RX queues per set to be different sizes - Don't split up TX mbufs before transmit - Allow a completion queue for TX as well as RX - Pass the RX budget to isc_rxd_available() to allow an earlier return and avoid multiple calls
Submitted by: shurd Reviewed by: gallatin Approved by: scottl Differential Revision: https://reviews.freebsd.org/D7393
show more ...
|
| #
96c85efb |
| 06-Jul-2016 |
Nathan Whitehorn <[email protected]> |
Replace a number of conflations of mp_ncpus and mp_maxid with either mp_maxid or CPU_FOREACH() as appropriate. This fixes a number of places in the kernel that assumed CPU IDs are dense in [0, mp_ncp
Replace a number of conflations of mp_ncpus and mp_maxid with either mp_maxid or CPU_FOREACH() as appropriate. This fixes a number of places in the kernel that assumed CPU IDs are dense in [0, mp_ncpus) and would try, for example, to run tasks on CPUs that did not exist or to allocate too few buffers on systems with sparse CPU IDs in which there are holes in the range and mp_maxid > mp_ncpus. Such circumstances generally occur on systems with SMT, but on which SMT is disabled. This patch restores system operation at least on POWER8 systems configured in this way.
There are a number of other places in the kernel with potential problems in these situations, but where sparse CPU IDs are not currently known to occur, mostly in the ARM machine-dependent code. These will be fixed in a follow-up commit after the stable/11 branch.
PR: kern/210106 Reviewed by: jhb Approved by: re (glebius)
show more ...
|
| #
f3c8e16e |
| 02-Jun-2016 |
Mateusz Guzik <[email protected]> |
taskqueue: plug a leak in _taskqueue_create
While here make some style fixes and postpone the sprintf so that it is only done when the function can no longer fail.
CID: 1356041
|
| #
7107bed0 |
| 21-May-2016 |
Andriy Gapon <[email protected]> |
fix loss of taskqueue wakeups (introduced in r300113)
Submitted by: kmacy Tested by: dchagin
|
| #
7e52504f |
| 19-May-2016 |
Scott Long <[email protected]> |
Adjust the creation of tq_name so it can be freed correctly
Reviewed by: jhb, allanjude Differential Revision: D6454
|
| #
4c7070db |
| 18-May-2016 |
Scott Long <[email protected]> |
Import the 'iflib' API library for network drivers. From the author:
"iflib is a library to eliminate the need for frequently duplicated device independent logic propagated (poorly) across many net
Import the 'iflib' API library for network drivers. From the author:
"iflib is a library to eliminate the need for frequently duplicated device independent logic propagated (poorly) across many network drivers."
Participation is purely optional. The IFLIB kernel config option is provided for drivers that want to transition between legacy and iflib modes of operation. ixl and ixgbe driver conversions will be committed shortly. We hope to see participation from the Broadcom and maybe Chelsio drivers in the near future.
Submitted by: [email protected] Reviewed by: gallatin Differential Revision: D5211
show more ...
|
|
Revision tags: release/10.3.0 |
|
| #
cbc4d2db |
| 01-Mar-2016 |
John Baldwin <[email protected]> |
Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compa
Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compat shim to go.
Submitted by: Howard Su <[email protected]> Reviewed by: sephe Differential Revision: https://reviews.freebsd.org/D5131
show more ...
|
| #
7c4676dd |
| 13-Nov-2015 |
Randall Stewart <[email protected]> |
This fixes several places where callout_stops return is examined. The new return codes of -1 were mistakenly being considered "true". Callout_stop now returns -1 to indicate the callout had either al
This fixes several places where callout_stops return is examined. The new return codes of -1 were mistakenly being considered "true". Callout_stop now returns -1 to indicate the callout had either already completed or was not running and 0 to indicate it could not be stopped. Also update the manual page to make it more consistent no non-zero in the callout_stop or callout_reset descriptions.
MFC after: 1 Month with associated callout change.
show more ...
|
|
Revision tags: release/10.2.0 |
|
| #
eb3d0c5d |
| 26-May-2015 |
Xin LI <[email protected]> |
MFuser/delphij/zfs-arc-rebase@r281754:
In r256613, taskqueue_enqueue_locked() have been modified to release the task queue lock before returning. In r276665, taskqueue_drain_all() will call taskque
MFuser/delphij/zfs-arc-rebase@r281754:
In r256613, taskqueue_enqueue_locked() have been modified to release the task queue lock before returning. In r276665, taskqueue_drain_all() will call taskqueue_enqueue_locked() to insert the barrier task into the queue, but did not reacquire the lock after it but later code expects the lock still being held (e.g. TQ_SLEEP()).
The barrier task is special and if we release then reacquire the lock, there would be a small race window where a high priority task could sneak into the queue. Looking more closely, the race seems to be tolerable but is undesirable from semantics standpoint.
To solve this, in taskqueue_drain_tq_queue(), instead of directly calling taskqueue_enqueue_locked(), insert the barrier task directly without releasing the lock.
show more ...
|
| #
75493a82 |
| 25-Feb-2015 |
Adrian Chadd <[email protected]> |
Remove taskqueue_start_threads_pinned(); there's noa generic cpuset version of this.
Sponsored by: Norse Corp, Inc.
|
| #
bfa102ca |
| 17-Feb-2015 |
Adrian Chadd <[email protected]> |
Implement taskqueue_start_threads_cpuset().
This is a more generic version of taskqueue_start_threads_pinned() which only supports a single cpuid.
This originally came from John Baldwin <jhb@> who
Implement taskqueue_start_threads_cpuset().
This is a more generic version of taskqueue_start_threads_pinned() which only supports a single cpuid.
This originally came from John Baldwin <jhb@> who implemented it as part of a push towards NUMA awareness in drivers. I started implementing something similar for RSS and NUMA, then found he already did it.
I'd like to axe taskqueue_start_threads_pinned() so it doesn't become part of a longer-term API. (Read: hps@ wants to MFC things, and if I don't do this soon, he'll MFC what's here. :-)
I have a follow-up commit which converts the intel drivers over to using the cpuset version of this function, so we can eventually nuke the the pinned version.
Tested:
* igb, ixgbe
Obtained from: jhbbsd
show more ...
|
| #
5b326a32 |
| 04-Jan-2015 |
Justin T. Gibbs <[email protected]> |
Prevent live-lock and access of destroyed data in taskqueue_drain_all().
Phabric: https://reviews.freebsd.org/D1247 Reviewed by: jhb, avg Sponsored by: Spectra Logic Corporation
sys/kern_subr_taskq
Prevent live-lock and access of destroyed data in taskqueue_drain_all().
Phabric: https://reviews.freebsd.org/D1247 Reviewed by: jhb, avg Sponsored by: Spectra Logic Corporation
sys/kern_subr_taskqueue.c: Modify taskqueue_drain_all() processing to use a temporary "barrier task", rather than rely on a user task that may be destroyed during taskqueue_drain_all()'s execution. The barrier task is queued behind all previously queued tasks and then has its priority elevated so that future tasks cannot pass it in the queue.
Use a similar barrier scheme to drain threads processing current tasks. This requires taskqueue_run_locked() to insert and remove the taskqueue_busy object for the running thread for every task processed.
share/man/man9/taskqueue.9: Remove warning about live-lock issues with taskqueue_drain_all() and indicate that it does not wait for tasks queued after it begins processing.
show more ...
|
| #
2c6bf3d9 |
| 30-Nov-2014 |
Justin T. Gibbs <[email protected]> |
Remove trailing whitespace.
|
|
Revision tags: release/10.1.0 |
|
| #
3e400979 |
| 07-Aug-2014 |
Andrey V. Elsukov <[email protected]> |
Temporary revert r269661, it looks like the patch isn't complete.
|
| #
c60e497a |
| 07-Aug-2014 |
Andrey V. Elsukov <[email protected]> |
Use cpuset_setithread() to apply cpu mask to taskq threads.
Sponsored by: Yandex LLC
|
|
Revision tags: release/9.3.0 |
|
| #
924aaf69 |
| 01-Jun-2014 |
Adrian Chadd <[email protected]> |
Pin the right thread.
This _was_ right, a last minute suggestion and not enough testing makes Adrian a bad boy.
Tested:
* igb(4) with RSS patches, by hand verifying each igb(4) taskqueue tid fro
Pin the right thread.
This _was_ right, a last minute suggestion and not enough testing makes Adrian a bad boy.
Tested:
* igb(4) with RSS patches, by hand verifying each igb(4) taskqueue tid from procstat -ka using cpuset -g -t <tid>.
show more ...
|