2006-06-25 20:48:02 -04:00
|
|
|
/*
|
|
|
|
|
* Task management functions.
|
|
|
|
|
*
|
2009-03-07 11:25:21 -05:00
|
|
|
* Copyright 2000-2009 Willy Tarreau <w@1wt.eu>
|
2006-06-25 20:48:02 -04:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
2009-03-08 17:25:28 -04:00
|
|
|
#include <string.h>
|
|
|
|
|
|
2020-06-09 03:07:15 -04:00
|
|
|
#include <import/eb32sctree.h>
|
|
|
|
|
#include <import/eb32tree.h>
|
|
|
|
|
|
2020-05-27 06:58:42 -04:00
|
|
|
#include <haproxy/api.h>
|
2021-10-06 13:54:09 -04:00
|
|
|
#include <haproxy/activity.h>
|
2020-06-24 05:11:02 -04:00
|
|
|
#include <haproxy/cfgparse.h>
|
2021-10-08 03:33:24 -04:00
|
|
|
#include <haproxy/clock.h>
|
2020-06-09 03:07:15 -04:00
|
|
|
#include <haproxy/fd.h>
|
2020-05-27 12:01:47 -04:00
|
|
|
#include <haproxy/list.h>
|
2020-06-09 03:07:15 -04:00
|
|
|
#include <haproxy/pool.h>
|
2020-06-04 11:25:40 -04:00
|
|
|
#include <haproxy/task.h>
|
2020-06-09 03:07:15 -04:00
|
|
|
#include <haproxy/tools.h>
|
2006-06-25 20:48:02 -04:00
|
|
|
|
2021-05-08 14:10:13 -04:00
|
|
|
extern struct task *process_stream(struct task *t, void *context, unsigned int state);
|
2007-04-29 04:41:56 -04:00
|
|
|
|
2018-11-26 05:58:30 -05:00
|
|
|
DECLARE_POOL(pool_head_task, "task", sizeof(struct task));
|
|
|
|
|
DECLARE_POOL(pool_head_tasklet, "tasklet", sizeof(struct tasklet));
|
2006-06-25 20:48:02 -04:00
|
|
|
|
2017-07-12 08:31:10 -04:00
|
|
|
/* This is the memory pool containing all the signal structs. These
|
2018-11-15 17:19:23 -05:00
|
|
|
* struct are used to store each required signal between two tasks.
|
2017-07-12 08:31:10 -04:00
|
|
|
*/
|
2018-11-26 05:58:30 -05:00
|
|
|
DECLARE_POOL(pool_head_notification, "notification", sizeof(struct notification));
|
2017-07-12 08:31:10 -04:00
|
|
|
|
2018-07-26 12:53:28 -04:00
|
|
|
volatile unsigned long global_tasks_mask = 0; /* Mask of threads with tasks in the global runqueue */
|
2009-03-21 05:01:42 -04:00
|
|
|
unsigned int niced_tasks = 0; /* number of niced tasks in the run queue */
|
2017-03-30 09:37:25 -04:00
|
|
|
|
2018-11-25 14:12:18 -05:00
|
|
|
__decl_aligned_spinlock(rq_lock); /* spin lock related to run queue */
|
2019-05-28 12:48:07 -04:00
|
|
|
__decl_aligned_rwlock(wq_lock); /* RW lock related to the wait queue */
|
2006-06-25 20:48:02 -04:00
|
|
|
|
2018-06-06 08:22:03 -04:00
|
|
|
#ifdef USE_THREAD
|
2021-02-20 06:49:54 -05:00
|
|
|
struct eb_root timers; /* sorted timers tree, global, accessed under wq_lock */
|
|
|
|
|
struct eb_root rqueue; /* tree constituting the global run queue, accessed under rq_lock */
|
2021-02-25 01:51:18 -05:00
|
|
|
unsigned int grq_total; /* total number of entries in the global run queue, atomic */
|
2021-02-20 06:49:54 -05:00
|
|
|
static unsigned int global_rqueue_ticks; /* insertion count in the grq, use rq_lock */
|
2018-06-06 08:22:03 -04:00
|
|
|
#endif
|
2018-10-15 08:52:21 -04:00
|
|
|
|
2018-10-15 10:12:48 -04:00
|
|
|
|
2020-06-30 05:48:48 -04:00
|
|
|
|
|
|
|
|
/* Flags the task <t> for immediate destruction and puts it into its first
|
|
|
|
|
* thread's shared tasklet list if not yet queued/running. This will bypass
|
|
|
|
|
* the priority scheduling and make the task show up as fast as possible in
|
|
|
|
|
* the other thread's queue. Note that this operation isn't idempotent and is
|
|
|
|
|
* not supposed to be run on the same task from multiple threads at once. It's
|
|
|
|
|
* the caller's responsibility to make sure it is the only one able to kill the
|
|
|
|
|
* task.
|
|
|
|
|
*/
|
|
|
|
|
void task_kill(struct task *t)
|
|
|
|
|
{
|
2021-03-02 10:09:26 -05:00
|
|
|
unsigned int state = t->state;
|
2020-06-30 05:48:48 -04:00
|
|
|
unsigned int thr;
|
|
|
|
|
|
|
|
|
|
BUG_ON(state & TASK_KILLED);
|
|
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
|
while (state & (TASK_RUNNING | TASK_QUEUED)) {
|
|
|
|
|
/* task already in the queue and about to be executed,
|
|
|
|
|
* or even currently running. Just add the flag and be
|
|
|
|
|
* done with it, the process loop will detect it and kill
|
|
|
|
|
* it. The CAS will fail if we arrive too late.
|
|
|
|
|
*/
|
|
|
|
|
if (_HA_ATOMIC_CAS(&t->state, &state, state | TASK_KILLED))
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We'll have to wake it up, but we must also secure it so that
|
|
|
|
|
* it doesn't vanish under us. TASK_QUEUED guarantees nobody will
|
|
|
|
|
* add past us.
|
|
|
|
|
*/
|
|
|
|
|
if (_HA_ATOMIC_CAS(&t->state, &state, state | TASK_QUEUED | TASK_KILLED)) {
|
|
|
|
|
/* Bypass the tree and go directly into the shared tasklet list.
|
|
|
|
|
* Note: that's a task so it must be accounted for as such. Pick
|
|
|
|
|
* the task's first thread for the job.
|
|
|
|
|
*/
|
|
|
|
|
thr = my_ffsl(t->thread_mask) - 1;
|
2020-07-02 08:14:00 -04:00
|
|
|
|
|
|
|
|
/* Beware: tasks that have never run don't have their ->list empty yet! */
|
2021-10-01 05:30:33 -04:00
|
|
|
MT_LIST_APPEND(&ha_thread_ctx[thr].shared_tasklet_list,
|
2022-01-28 03:48:12 -05:00
|
|
|
list_to_mt_list(&((struct tasklet *)t)->list));
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_INC(&ha_thread_ctx[thr].rq_total);
|
|
|
|
|
_HA_ATOMIC_INC(&ha_thread_ctx[thr].tasks_in_list);
|
2020-07-02 08:14:00 -04:00
|
|
|
if (sleeping_thread_mask & (1UL << thr)) {
|
|
|
|
|
_HA_ATOMIC_AND(&sleeping_thread_mask, ~(1UL << thr));
|
|
|
|
|
wake_thread(thr);
|
2020-06-30 05:48:48 -04:00
|
|
|
}
|
2020-07-02 08:14:00 -04:00
|
|
|
return;
|
2020-06-30 05:48:48 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-28 10:12:57 -04:00
|
|
|
/* Equivalent of task_kill for tasklets. Mark the tasklet <t> for destruction.
|
|
|
|
|
* It will be deleted on the next scheduler invocation. This function is
|
|
|
|
|
* thread-safe : a thread can kill a tasklet of another thread.
|
|
|
|
|
*/
|
|
|
|
|
void tasklet_kill(struct tasklet *t)
|
|
|
|
|
{
|
|
|
|
|
unsigned int state = t->state;
|
|
|
|
|
unsigned int thr;
|
|
|
|
|
|
|
|
|
|
BUG_ON(state & TASK_KILLED);
|
|
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
|
while (state & (TASK_IN_LIST)) {
|
|
|
|
|
/* Tasklet already in the list ready to be executed. Add
|
|
|
|
|
* the killed flag and wait for the process loop to
|
|
|
|
|
* detect it.
|
|
|
|
|
*/
|
|
|
|
|
if (_HA_ATOMIC_CAS(&t->state, &state, state | TASK_KILLED))
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Mark the tasklet as killed and wake the thread to process it
|
|
|
|
|
* as soon as possible.
|
|
|
|
|
*/
|
|
|
|
|
if (_HA_ATOMIC_CAS(&t->state, &state, state | TASK_IN_LIST | TASK_KILLED)) {
|
|
|
|
|
thr = t->tid > 0 ? t->tid: tid;
|
2021-10-01 05:30:33 -04:00
|
|
|
MT_LIST_APPEND(&ha_thread_ctx[thr].shared_tasklet_list,
|
2022-01-28 03:48:12 -05:00
|
|
|
list_to_mt_list(&t->list));
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_INC(&ha_thread_ctx[thr].rq_total);
|
2021-07-28 10:12:57 -04:00
|
|
|
if (sleeping_thread_mask & (1UL << thr)) {
|
|
|
|
|
_HA_ATOMIC_AND(&sleeping_thread_mask, ~(1UL << thr));
|
|
|
|
|
wake_thread(thr);
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-24 11:51:38 -05:00
|
|
|
/* Do not call this one, please use tasklet_wakeup_on() instead, as this one is
|
|
|
|
|
* the slow path of tasklet_wakeup_on() which performs some preliminary checks
|
|
|
|
|
* and sets TASK_IN_LIST before calling this one. A negative <thr> designates
|
|
|
|
|
* the current thread.
|
|
|
|
|
*/
|
|
|
|
|
void __tasklet_wakeup_on(struct tasklet *tl, int thr)
|
|
|
|
|
{
|
|
|
|
|
if (likely(thr < 0)) {
|
|
|
|
|
/* this tasklet runs on the caller thread */
|
2021-02-26 04:13:40 -05:00
|
|
|
if (tl->state & TASK_HEAVY) {
|
2021-10-01 05:30:33 -04:00
|
|
|
LIST_APPEND(&th_ctx->tasklets[TL_HEAVY], &tl->list);
|
|
|
|
|
th_ctx->tl_class_mask |= 1 << TL_HEAVY;
|
2021-02-26 04:13:40 -05:00
|
|
|
}
|
|
|
|
|
else if (tl->state & TASK_SELF_WAKING) {
|
2021-10-01 05:30:33 -04:00
|
|
|
LIST_APPEND(&th_ctx->tasklets[TL_BULK], &tl->list);
|
|
|
|
|
th_ctx->tl_class_mask |= 1 << TL_BULK;
|
2021-02-24 11:51:38 -05:00
|
|
|
}
|
2021-10-01 05:30:33 -04:00
|
|
|
else if ((struct task *)tl == th_ctx->current) {
|
2021-02-24 11:51:38 -05:00
|
|
|
_HA_ATOMIC_OR(&tl->state, TASK_SELF_WAKING);
|
2021-10-01 05:30:33 -04:00
|
|
|
LIST_APPEND(&th_ctx->tasklets[TL_BULK], &tl->list);
|
|
|
|
|
th_ctx->tl_class_mask |= 1 << TL_BULK;
|
2021-02-24 11:51:38 -05:00
|
|
|
}
|
2021-10-01 05:30:33 -04:00
|
|
|
else if (th_ctx->current_queue < 0) {
|
|
|
|
|
LIST_APPEND(&th_ctx->tasklets[TL_URGENT], &tl->list);
|
|
|
|
|
th_ctx->tl_class_mask |= 1 << TL_URGENT;
|
2021-02-24 11:51:38 -05:00
|
|
|
}
|
|
|
|
|
else {
|
2021-10-01 05:30:33 -04:00
|
|
|
LIST_APPEND(&th_ctx->tasklets[th_ctx->current_queue], &tl->list);
|
|
|
|
|
th_ctx->tl_class_mask |= 1 << th_ctx->current_queue;
|
2021-02-24 11:51:38 -05:00
|
|
|
}
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_INC(&th_ctx->rq_total);
|
2021-02-24 11:51:38 -05:00
|
|
|
} else {
|
|
|
|
|
/* this tasklet runs on a specific thread. */
|
2022-01-28 03:48:12 -05:00
|
|
|
MT_LIST_APPEND(&ha_thread_ctx[thr].shared_tasklet_list, list_to_mt_list(&tl->list));
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_INC(&ha_thread_ctx[thr].rq_total);
|
2021-02-24 11:51:38 -05:00
|
|
|
if (sleeping_thread_mask & (1UL << thr)) {
|
|
|
|
|
_HA_ATOMIC_AND(&sleeping_thread_mask, ~(1UL << thr));
|
|
|
|
|
wake_thread(thr);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-03-07 11:25:21 -05:00
|
|
|
/* Puts the task <t> in run queue at a position depending on t->nice. <t> is
|
|
|
|
|
* returned. The nice value assigns boosts in 32th of the run queue size. A
|
2016-12-06 03:15:30 -05:00
|
|
|
* nice value of -1024 sets the task to -tasks_run_queue*32, while a nice value
|
|
|
|
|
* of 1024 sets the task to tasks_run_queue*32. The state flags are cleared, so
|
|
|
|
|
* the caller will have to set its flags after this call.
|
2009-03-07 11:25:21 -05:00
|
|
|
* The task must not already be in the run queue. If unsure, use the safer
|
|
|
|
|
* task_wakeup() function.
|
2008-06-30 01:51:00 -04:00
|
|
|
*/
|
2021-02-24 10:41:11 -05:00
|
|
|
void __task_wakeup(struct task *t)
|
2007-04-30 07:15:14 -04:00
|
|
|
{
|
2021-10-01 05:30:33 -04:00
|
|
|
struct eb_root *root = &th_ctx->rqueue;
|
2021-02-24 10:41:11 -05:00
|
|
|
|
2018-06-06 08:22:03 -04:00
|
|
|
#ifdef USE_THREAD
|
2021-02-24 10:41:11 -05:00
|
|
|
if (t->thread_mask != tid_bit && global.nbthread != 1) {
|
|
|
|
|
root = &rqueue;
|
|
|
|
|
|
2021-04-06 07:53:36 -04:00
|
|
|
_HA_ATOMIC_INC(&grq_total);
|
2018-05-18 12:38:23 -04:00
|
|
|
HA_SPIN_LOCK(TASK_RQ_LOCK, &rq_lock);
|
2021-02-24 09:10:07 -05:00
|
|
|
|
2019-04-17 13:10:22 -04:00
|
|
|
global_tasks_mask |= t->thread_mask;
|
2021-02-20 06:49:54 -05:00
|
|
|
t->rq.key = ++global_rqueue_ticks;
|
2019-04-18 08:12:51 -04:00
|
|
|
__ha_barrier_store();
|
2021-02-20 06:49:54 -05:00
|
|
|
} else
|
2018-07-26 09:25:49 -04:00
|
|
|
#endif
|
2021-02-24 09:10:07 -05:00
|
|
|
{
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_INC(&th_ctx->rq_total);
|
|
|
|
|
t->rq.key = ++th_ctx->rqueue_ticks;
|
2021-02-24 09:10:07 -05:00
|
|
|
}
|
2008-06-30 01:51:00 -04:00
|
|
|
|
|
|
|
|
if (likely(t->nice)) {
|
|
|
|
|
int offset;
|
|
|
|
|
|
2021-04-06 07:53:36 -04:00
|
|
|
_HA_ATOMIC_INC(&niced_tasks);
|
2019-04-15 03:18:31 -04:00
|
|
|
offset = t->nice * (int)global.tune.runqueue_depth;
|
2009-03-07 11:25:21 -05:00
|
|
|
t->rq.key += offset;
|
2008-06-30 01:51:00 -04:00
|
|
|
}
|
|
|
|
|
|
2019-04-25 02:57:41 -04:00
|
|
|
if (task_profiling_mask & tid_bit)
|
2018-05-31 08:48:54 -04:00
|
|
|
t->call_date = now_mono_time();
|
|
|
|
|
|
2018-05-18 12:38:23 -04:00
|
|
|
eb32sc_insert(root, &t->rq, t->thread_mask);
|
2021-02-24 10:41:11 -05:00
|
|
|
|
2018-06-06 08:22:03 -04:00
|
|
|
#ifdef USE_THREAD
|
2018-05-18 12:38:23 -04:00
|
|
|
if (root == &rqueue) {
|
2019-03-08 12:48:47 -05:00
|
|
|
_HA_ATOMIC_OR(&t->state, TASK_GLOBAL);
|
2018-05-18 12:38:23 -04:00
|
|
|
HA_SPIN_UNLOCK(TASK_RQ_LOCK, &rq_lock);
|
2021-02-24 10:13:03 -05:00
|
|
|
|
2021-02-24 10:44:51 -05:00
|
|
|
/* If all threads that are supposed to handle this task are sleeping,
|
|
|
|
|
* wake one.
|
|
|
|
|
*/
|
|
|
|
|
if ((((t->thread_mask & all_threads_mask) & sleeping_thread_mask) ==
|
|
|
|
|
(t->thread_mask & all_threads_mask))) {
|
|
|
|
|
unsigned long m = (t->thread_mask & all_threads_mask) &~ tid_bit;
|
2019-03-14 19:23:10 -04:00
|
|
|
|
2021-02-24 10:44:51 -05:00
|
|
|
m = (m & (m - 1)) ^ m; // keep lowest bit set
|
|
|
|
|
_HA_ATOMIC_AND(&sleeping_thread_mask, ~m);
|
|
|
|
|
wake_thread(my_ffsl(m) - 1);
|
|
|
|
|
}
|
2019-03-14 19:23:10 -04:00
|
|
|
}
|
2018-07-27 11:14:41 -04:00
|
|
|
#endif
|
2018-05-18 12:38:23 -04:00
|
|
|
return;
|
2007-04-30 07:15:14 -04:00
|
|
|
}
|
2007-05-12 16:35:00 -04:00
|
|
|
|
2007-04-29 04:41:56 -04:00
|
|
|
/*
|
2009-03-08 11:35:27 -04:00
|
|
|
* __task_queue()
|
2007-04-29 04:41:56 -04:00
|
|
|
*
|
2018-10-15 08:52:21 -04:00
|
|
|
* Inserts a task into wait queue <wq> at the position given by its expiration
|
2009-03-07 11:25:21 -05:00
|
|
|
* date. It does not matter if the task was already in the wait queue or not,
|
2021-09-30 10:38:09 -04:00
|
|
|
* as it will be unlinked. The task MUST NOT have an infinite expiration timer.
|
2009-03-21 05:01:42 -04:00
|
|
|
* Last, tasks must not be queued further than the end of the tree, which is
|
|
|
|
|
* between <now_ms> and <now_ms> + 2^31 ms (now+24days in 32bit).
|
2009-03-08 11:35:27 -04:00
|
|
|
*
|
|
|
|
|
* This function should not be used directly, it is meant to be called by the
|
|
|
|
|
* inline version of task_queue() which performs a few cheap preliminary tests
|
2018-10-15 08:52:21 -04:00
|
|
|
* before deciding to call __task_queue(). Moreover this function doesn't care
|
|
|
|
|
* at all about locking so the caller must be careful when deciding whether to
|
|
|
|
|
* lock or not around this call.
|
2007-04-29 04:41:56 -04:00
|
|
|
*/
|
2018-10-15 08:52:21 -04:00
|
|
|
void __task_queue(struct task *task, struct eb_root *wq)
|
2006-06-25 20:48:02 -04:00
|
|
|
{
|
2020-07-22 08:29:42 -04:00
|
|
|
#ifdef USE_THREAD
|
|
|
|
|
BUG_ON((wq == &timers && !(task->state & TASK_SHARED_WQ)) ||
|
2021-10-01 05:30:33 -04:00
|
|
|
(wq == &th_ctx->timers && (task->state & TASK_SHARED_WQ)) ||
|
|
|
|
|
(wq != &timers && wq != &th_ctx->timers));
|
2020-07-22 08:29:42 -04:00
|
|
|
#endif
|
2021-09-30 10:38:09 -04:00
|
|
|
/* if this happens the process is doomed anyway, so better catch it now
|
|
|
|
|
* so that we have the caller in the stack.
|
|
|
|
|
*/
|
|
|
|
|
BUG_ON(task->expire == TICK_ETERNITY);
|
2020-07-22 08:29:42 -04:00
|
|
|
|
2009-03-08 11:35:27 -04:00
|
|
|
if (likely(task_in_wq(task)))
|
2009-03-07 11:25:21 -05:00
|
|
|
__task_unlink_wq(task);
|
|
|
|
|
|
|
|
|
|
/* the task is not in the queue now */
|
2009-03-21 05:01:42 -04:00
|
|
|
task->wq.key = task->expire;
|
2008-06-29 11:00:59 -04:00
|
|
|
#ifdef DEBUG_CHECK_INVALID_EXPIRATION_DATES
|
2009-03-21 05:01:42 -04:00
|
|
|
if (tick_is_lt(task->wq.key, now_ms))
|
2008-06-29 11:00:59 -04:00
|
|
|
/* we're queuing too far away or in the past (most likely) */
|
2009-03-07 11:25:21 -05:00
|
|
|
return;
|
2008-06-29 11:00:59 -04:00
|
|
|
#endif
|
2008-07-05 12:16:19 -04:00
|
|
|
|
2018-10-15 08:52:21 -04:00
|
|
|
eb32_insert(wq, &task->wq);
|
2007-04-29 04:41:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2008-06-24 02:17:16 -04:00
|
|
|
* Extract all expired timers from the timer queue, and wakes up all
|
MINOR: tasks: split wake_expired_tasks() in two parts to avoid useless wakeups
We used to have wake_expired_tasks() wake up tasks and return the next
expiration delay. The problem this causes is that we have to call it just
before poll() in order to consider latest timers, but this also means that
we don't wake up all newly expired tasks upon return from poll(), which
thus systematically requires a second poll() round.
This is visible when running any scheduled task like a health check, as there
are systematically two poll() calls, one with the interval, nothing is done
after it, and another one with a zero delay, and the task is called:
listen test
bind *:8001
server s1 127.0.0.1:1111 check
09:37:38.200959 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8696843}) = 0
09:37:38.200967 epoll_wait(3, [], 200, 1000) = 0
09:37:39.202459 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8712467}) = 0
>> nothing run here, as the expired task was not woken up yet.
09:37:39.202497 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8715766}) = 0
09:37:39.202505 epoll_wait(3, [], 200, 0) = 0
09:37:39.202513 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8719064}) = 0
>> now the expired task was woken up
09:37:39.202522 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:37:39.202537 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:37:39.202565 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:37:39.202577 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:37:39.202585 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:37:39.202659 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:37:39.202673 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8814713}) = 0
09:37:39.202683 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:37:39.202693 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8818617}) = 0
09:37:39.202701 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:37:39.202715 close(7) = 0
Let's instead split the function in two parts:
- the first part, wake_expired_tasks(), called just before
process_runnable_tasks(), wakes up all expired tasks; it doesn't
compute any timeout.
- the second part, next_timer_expiry(), called just before poll(),
only computes the next timeout for the current thread.
Thanks to this, all expired tasks are properly woken up when leaving
poll, and each poll call's timeout remains up to date:
09:41:16.270449 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10223556}) = 0
09:41:16.270457 epoll_wait(3, [], 200, 999) = 0
09:41:17.270130 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10238572}) = 0
09:41:17.270157 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:41:17.270194 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:41:17.270204 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:41:17.270216 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:41:17.270224 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:41:17.270299 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:41:17.270314 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10337841}) = 0
09:41:17.270323 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:41:17.270332 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10341860}) = 0
09:41:17.270340 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:41:17.270367 close(7) = 0
This may be backported to 2.1 and 2.0 though it's unlikely to bring any
user-visible improvement except to clarify debugging.
2019-12-11 02:12:23 -05:00
|
|
|
* associated tasks.
|
2007-04-29 04:41:56 -04:00
|
|
|
*/
|
MINOR: tasks: split wake_expired_tasks() in two parts to avoid useless wakeups
We used to have wake_expired_tasks() wake up tasks and return the next
expiration delay. The problem this causes is that we have to call it just
before poll() in order to consider latest timers, but this also means that
we don't wake up all newly expired tasks upon return from poll(), which
thus systematically requires a second poll() round.
This is visible when running any scheduled task like a health check, as there
are systematically two poll() calls, one with the interval, nothing is done
after it, and another one with a zero delay, and the task is called:
listen test
bind *:8001
server s1 127.0.0.1:1111 check
09:37:38.200959 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8696843}) = 0
09:37:38.200967 epoll_wait(3, [], 200, 1000) = 0
09:37:39.202459 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8712467}) = 0
>> nothing run here, as the expired task was not woken up yet.
09:37:39.202497 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8715766}) = 0
09:37:39.202505 epoll_wait(3, [], 200, 0) = 0
09:37:39.202513 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8719064}) = 0
>> now the expired task was woken up
09:37:39.202522 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:37:39.202537 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:37:39.202565 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:37:39.202577 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:37:39.202585 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:37:39.202659 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:37:39.202673 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8814713}) = 0
09:37:39.202683 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:37:39.202693 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8818617}) = 0
09:37:39.202701 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:37:39.202715 close(7) = 0
Let's instead split the function in two parts:
- the first part, wake_expired_tasks(), called just before
process_runnable_tasks(), wakes up all expired tasks; it doesn't
compute any timeout.
- the second part, next_timer_expiry(), called just before poll(),
only computes the next timeout for the current thread.
Thanks to this, all expired tasks are properly woken up when leaving
poll, and each poll call's timeout remains up to date:
09:41:16.270449 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10223556}) = 0
09:41:16.270457 epoll_wait(3, [], 200, 999) = 0
09:41:17.270130 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10238572}) = 0
09:41:17.270157 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:41:17.270194 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:41:17.270204 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:41:17.270216 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:41:17.270224 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:41:17.270299 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:41:17.270314 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10337841}) = 0
09:41:17.270323 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:41:17.270332 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10341860}) = 0
09:41:17.270340 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:41:17.270367 close(7) = 0
This may be backported to 2.1 and 2.0 though it's unlikely to bring any
user-visible improvement except to clarify debugging.
2019-12-11 02:12:23 -05:00
|
|
|
void wake_expired_tasks()
|
2007-04-29 04:41:56 -04:00
|
|
|
{
|
2021-10-01 05:30:33 -04:00
|
|
|
struct thread_ctx * const tt = th_ctx; // thread's tasks
|
BUG/MEDIUM: task: bound the number of tasks picked from the wait queue at once
There is a theorical problem in the wait queue, which is that with many
threads, one could spend a lot of time looping on the newly expired tasks,
causing a lot of contention on the global wq_lock and on the global
rq_lock. This initially sounds bening, but if another thread does just
a task_schedule() or task_queue(), it might end up waiting for a long
time on this lock, and this wait time will count on its execution budget,
degrading the end user's experience and possibly risking to trigger the
watchdog if that lasts too long.
The simplest (and backportable) solution here consists in bounding the
number of expired tasks that may be picked from the global wait queue at
once by a thread, given that all other ones will do it as well anyway.
We don't need to pick more than global.tune.runqueue_depth tasks at once
as we won't process more, so this counter is updated for both the local
and the global queues: threads with more local expired tasks will pick
less global tasks and conversely, keeping the load balanced between all
threads. This will guarantee a much lower latency if/when wakeup storms
happen (e.g. hundreds of thousands of synchronized health checks).
Note that some crashes have been witnessed with 1/4 of the threads in
wake_expired_tasks() and, while the issue might or might not be related,
not having reasonable bounds here definitely justifies why we can spend
so much time there.
This patch should be backported, probably as far as 2.0 (maybe with
some adaptations).
2020-10-16 03:26:22 -04:00
|
|
|
int max_processed = global.tune.runqueue_depth;
|
2007-04-29 04:41:56 -04:00
|
|
|
struct task *task;
|
2008-06-24 02:17:16 -04:00
|
|
|
struct eb32_node *eb;
|
2020-06-05 02:40:51 -04:00
|
|
|
__decl_thread(int key);
|
2008-06-29 11:00:59 -04:00
|
|
|
|
BUG/MEDIUM: task: bound the number of tasks picked from the wait queue at once
There is a theorical problem in the wait queue, which is that with many
threads, one could spend a lot of time looping on the newly expired tasks,
causing a lot of contention on the global wq_lock and on the global
rq_lock. This initially sounds bening, but if another thread does just
a task_schedule() or task_queue(), it might end up waiting for a long
time on this lock, and this wait time will count on its execution budget,
degrading the end user's experience and possibly risking to trigger the
watchdog if that lasts too long.
The simplest (and backportable) solution here consists in bounding the
number of expired tasks that may be picked from the global wait queue at
once by a thread, given that all other ones will do it as well anyway.
We don't need to pick more than global.tune.runqueue_depth tasks at once
as we won't process more, so this counter is updated for both the local
and the global queues: threads with more local expired tasks will pick
less global tasks and conversely, keeping the load balanced between all
threads. This will guarantee a much lower latency if/when wakeup storms
happen (e.g. hundreds of thousands of synchronized health checks).
Note that some crashes have been witnessed with 1/4 of the threads in
wake_expired_tasks() and, while the issue might or might not be related,
not having reasonable bounds here definitely justifies why we can spend
so much time there.
This patch should be backported, probably as far as 2.0 (maybe with
some adaptations).
2020-10-16 03:26:22 -04:00
|
|
|
while (max_processed-- > 0) {
|
2018-10-15 08:52:21 -04:00
|
|
|
lookup_next_local:
|
2019-09-24 01:19:08 -04:00
|
|
|
eb = eb32_lookup_ge(&tt->timers, now_ms - TIMER_LOOK_BACK);
|
2018-10-15 08:52:21 -04:00
|
|
|
if (!eb) {
|
|
|
|
|
/* we might have reached the end of the tree, typically because
|
|
|
|
|
* <now_ms> is in the first half and we're first scanning the last
|
|
|
|
|
* half. Let's loop back to the beginning of the tree now.
|
|
|
|
|
*/
|
2019-09-24 01:19:08 -04:00
|
|
|
eb = eb32_first(&tt->timers);
|
2018-10-15 08:52:21 -04:00
|
|
|
if (likely(!eb))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* It is possible that this task was left at an earlier place in the
|
|
|
|
|
* tree because a recent call to task_queue() has not moved it. This
|
|
|
|
|
* happens when the new expiration date is later than the old one.
|
|
|
|
|
* Since it is very unlikely that we reach a timeout anyway, it's a
|
|
|
|
|
* lot cheaper to proceed like this because we almost never update
|
|
|
|
|
* the tree. We may also find disabled expiration dates there. Since
|
|
|
|
|
* we have detached the task from the tree, we simply call task_queue
|
|
|
|
|
* to take care of this. Note that we might occasionally requeue it at
|
|
|
|
|
* the same place, before <eb>, so we have to check if this happens,
|
|
|
|
|
* and adjust <eb>, otherwise we may skip it which is not what we want.
|
|
|
|
|
* We may also not requeue the task (and not point eb at it) if its
|
2020-06-19 05:50:27 -04:00
|
|
|
* expiration time is not set. We also make sure we leave the real
|
|
|
|
|
* expiration date for the next task in the queue so that when calling
|
|
|
|
|
* next_timer_expiry() we're guaranteed to see the next real date and
|
|
|
|
|
* not the next apparent date. This is in order to avoid useless
|
|
|
|
|
* wakeups.
|
2018-10-15 08:52:21 -04:00
|
|
|
*/
|
2020-06-19 05:50:27 -04:00
|
|
|
|
|
|
|
|
task = eb32_entry(eb, struct task, wq);
|
|
|
|
|
if (tick_is_expired(task->expire, now_ms)) {
|
|
|
|
|
/* expired task, wake it up */
|
|
|
|
|
__task_unlink_wq(task);
|
|
|
|
|
task_wakeup(task, TASK_WOKEN_TIMER);
|
|
|
|
|
}
|
|
|
|
|
else if (task->expire != eb->key) {
|
|
|
|
|
/* task is not expired but its key doesn't match so let's
|
|
|
|
|
* update it and skip to next apparently expired task.
|
|
|
|
|
*/
|
|
|
|
|
__task_unlink_wq(task);
|
2018-10-15 08:52:21 -04:00
|
|
|
if (tick_isset(task->expire))
|
2019-09-24 01:19:08 -04:00
|
|
|
__task_queue(task, &tt->timers);
|
2018-10-15 08:52:21 -04:00
|
|
|
}
|
2020-06-19 05:50:27 -04:00
|
|
|
else {
|
2021-09-30 10:38:09 -04:00
|
|
|
/* task not expired and correctly placed. It may not be eternal. */
|
|
|
|
|
BUG_ON(task->expire == TICK_ETERNITY);
|
2020-06-19 05:50:27 -04:00
|
|
|
break;
|
|
|
|
|
}
|
2018-10-15 08:52:21 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef USE_THREAD
|
2019-05-28 12:57:25 -04:00
|
|
|
if (eb_is_empty(&timers))
|
|
|
|
|
goto leave;
|
|
|
|
|
|
|
|
|
|
HA_RWLOCK_RDLOCK(TASK_WQ_LOCK, &wq_lock);
|
|
|
|
|
eb = eb32_lookup_ge(&timers, now_ms - TIMER_LOOK_BACK);
|
|
|
|
|
if (!eb) {
|
|
|
|
|
eb = eb32_first(&timers);
|
|
|
|
|
if (likely(!eb)) {
|
|
|
|
|
HA_RWLOCK_RDUNLOCK(TASK_WQ_LOCK, &wq_lock);
|
|
|
|
|
goto leave;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
key = eb->key;
|
|
|
|
|
|
2020-10-16 03:31:41 -04:00
|
|
|
if (tick_is_lt(now_ms, key)) {
|
|
|
|
|
HA_RWLOCK_RDUNLOCK(TASK_WQ_LOCK, &wq_lock);
|
2019-05-28 12:57:25 -04:00
|
|
|
goto leave;
|
2020-10-16 03:31:41 -04:00
|
|
|
}
|
2019-05-28 12:57:25 -04:00
|
|
|
|
|
|
|
|
/* There's really something of interest here, let's visit the queue */
|
|
|
|
|
|
2020-10-16 03:31:41 -04:00
|
|
|
if (HA_RWLOCK_TRYRDTOSK(TASK_WQ_LOCK, &wq_lock)) {
|
|
|
|
|
/* if we failed to grab the lock it means another thread is
|
|
|
|
|
* already doing the same here, so let it do the job.
|
|
|
|
|
*/
|
|
|
|
|
HA_RWLOCK_RDUNLOCK(TASK_WQ_LOCK, &wq_lock);
|
|
|
|
|
goto leave;
|
|
|
|
|
}
|
|
|
|
|
|
2009-03-21 05:01:42 -04:00
|
|
|
while (1) {
|
2017-09-27 08:59:38 -04:00
|
|
|
lookup_next:
|
BUG/MEDIUM: task: bound the number of tasks picked from the wait queue at once
There is a theorical problem in the wait queue, which is that with many
threads, one could spend a lot of time looping on the newly expired tasks,
causing a lot of contention on the global wq_lock and on the global
rq_lock. This initially sounds bening, but if another thread does just
a task_schedule() or task_queue(), it might end up waiting for a long
time on this lock, and this wait time will count on its execution budget,
degrading the end user's experience and possibly risking to trigger the
watchdog if that lasts too long.
The simplest (and backportable) solution here consists in bounding the
number of expired tasks that may be picked from the global wait queue at
once by a thread, given that all other ones will do it as well anyway.
We don't need to pick more than global.tune.runqueue_depth tasks at once
as we won't process more, so this counter is updated for both the local
and the global queues: threads with more local expired tasks will pick
less global tasks and conversely, keeping the load balanced between all
threads. This will guarantee a much lower latency if/when wakeup storms
happen (e.g. hundreds of thousands of synchronized health checks).
Note that some crashes have been witnessed with 1/4 of the threads in
wake_expired_tasks() and, while the issue might or might not be related,
not having reasonable bounds here definitely justifies why we can spend
so much time there.
This patch should be backported, probably as far as 2.0 (maybe with
some adaptations).
2020-10-16 03:26:22 -04:00
|
|
|
if (max_processed-- <= 0)
|
|
|
|
|
break;
|
2017-03-30 09:37:25 -04:00
|
|
|
eb = eb32_lookup_ge(&timers, now_ms - TIMER_LOOK_BACK);
|
2017-09-27 08:59:38 -04:00
|
|
|
if (!eb) {
|
2009-03-21 05:01:42 -04:00
|
|
|
/* we might have reached the end of the tree, typically because
|
|
|
|
|
* <now_ms> is in the first half and we're first scanning the last
|
|
|
|
|
* half. Let's loop back to the beginning of the tree now.
|
|
|
|
|
*/
|
|
|
|
|
eb = eb32_first(&timers);
|
2017-11-05 13:09:27 -05:00
|
|
|
if (likely(!eb))
|
2009-03-21 05:01:42 -04:00
|
|
|
break;
|
|
|
|
|
}
|
2008-06-29 11:00:59 -04:00
|
|
|
|
2009-03-21 05:01:42 -04:00
|
|
|
task = eb32_entry(eb, struct task, wq);
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
|
|
|
|
|
/* Check for any competing run of the task (quite rare but may
|
|
|
|
|
* involve a dangerous concurrent access on task->expire). In
|
|
|
|
|
* order to protect against this, we'll take an exclusive access
|
|
|
|
|
* on TASK_RUNNING before checking/touching task->expire. If the
|
|
|
|
|
* task is already RUNNING on another thread, it will deal by
|
|
|
|
|
* itself with the requeuing so we must not do anything and
|
|
|
|
|
* simply quit the loop for now, because we cannot wait with the
|
|
|
|
|
* WQ lock held as this would prevent the running thread from
|
|
|
|
|
* requeuing the task. One annoying effect of holding RUNNING
|
|
|
|
|
* here is that a concurrent task_wakeup() will refrain from
|
|
|
|
|
* waking it up. This forces us to check for a wakeup after
|
|
|
|
|
* releasing the flag.
|
|
|
|
|
*/
|
|
|
|
|
if (HA_ATOMIC_FETCH_OR(&task->state, TASK_RUNNING) & TASK_RUNNING)
|
|
|
|
|
break;
|
|
|
|
|
|
2020-06-19 05:50:27 -04:00
|
|
|
if (tick_is_expired(task->expire, now_ms)) {
|
|
|
|
|
/* expired task, wake it up */
|
2020-10-16 03:31:41 -04:00
|
|
|
HA_RWLOCK_SKTOWR(TASK_WQ_LOCK, &wq_lock);
|
2020-06-19 05:50:27 -04:00
|
|
|
__task_unlink_wq(task);
|
2020-10-16 03:31:41 -04:00
|
|
|
HA_RWLOCK_WRTOSK(TASK_WQ_LOCK, &wq_lock);
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
task_drop_running(task, TASK_WOKEN_TIMER);
|
2020-06-19 05:50:27 -04:00
|
|
|
}
|
|
|
|
|
else if (task->expire != eb->key) {
|
|
|
|
|
/* task is not expired but its key doesn't match so let's
|
|
|
|
|
* update it and skip to next apparently expired task.
|
|
|
|
|
*/
|
2020-10-16 03:31:41 -04:00
|
|
|
HA_RWLOCK_SKTOWR(TASK_WQ_LOCK, &wq_lock);
|
2020-06-19 05:50:27 -04:00
|
|
|
__task_unlink_wq(task);
|
2017-11-05 13:09:27 -05:00
|
|
|
if (tick_isset(task->expire))
|
2020-07-22 08:12:45 -04:00
|
|
|
__task_queue(task, &timers);
|
2020-10-16 03:31:41 -04:00
|
|
|
HA_RWLOCK_WRTOSK(TASK_WQ_LOCK, &wq_lock);
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
task_drop_running(task, 0);
|
2017-09-27 08:59:38 -04:00
|
|
|
goto lookup_next;
|
2006-06-25 20:48:02 -04:00
|
|
|
}
|
2020-06-19 05:50:27 -04:00
|
|
|
else {
|
2021-09-30 10:38:09 -04:00
|
|
|
/* task not expired and correctly placed. It may not be eternal. */
|
|
|
|
|
BUG_ON(task->expire == TICK_ETERNITY);
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
task_drop_running(task, 0);
|
2020-06-19 05:50:27 -04:00
|
|
|
break;
|
|
|
|
|
}
|
2009-03-21 05:01:42 -04:00
|
|
|
}
|
2008-06-24 02:17:16 -04:00
|
|
|
|
2020-10-16 03:31:41 -04:00
|
|
|
HA_RWLOCK_SKUNLOCK(TASK_WQ_LOCK, &wq_lock);
|
2018-10-15 08:52:21 -04:00
|
|
|
#endif
|
2019-05-28 12:57:25 -04:00
|
|
|
leave:
|
MINOR: tasks: split wake_expired_tasks() in two parts to avoid useless wakeups
We used to have wake_expired_tasks() wake up tasks and return the next
expiration delay. The problem this causes is that we have to call it just
before poll() in order to consider latest timers, but this also means that
we don't wake up all newly expired tasks upon return from poll(), which
thus systematically requires a second poll() round.
This is visible when running any scheduled task like a health check, as there
are systematically two poll() calls, one with the interval, nothing is done
after it, and another one with a zero delay, and the task is called:
listen test
bind *:8001
server s1 127.0.0.1:1111 check
09:37:38.200959 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8696843}) = 0
09:37:38.200967 epoll_wait(3, [], 200, 1000) = 0
09:37:39.202459 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8712467}) = 0
>> nothing run here, as the expired task was not woken up yet.
09:37:39.202497 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8715766}) = 0
09:37:39.202505 epoll_wait(3, [], 200, 0) = 0
09:37:39.202513 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8719064}) = 0
>> now the expired task was woken up
09:37:39.202522 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:37:39.202537 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:37:39.202565 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:37:39.202577 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:37:39.202585 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:37:39.202659 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:37:39.202673 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8814713}) = 0
09:37:39.202683 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:37:39.202693 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8818617}) = 0
09:37:39.202701 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:37:39.202715 close(7) = 0
Let's instead split the function in two parts:
- the first part, wake_expired_tasks(), called just before
process_runnable_tasks(), wakes up all expired tasks; it doesn't
compute any timeout.
- the second part, next_timer_expiry(), called just before poll(),
only computes the next timeout for the current thread.
Thanks to this, all expired tasks are properly woken up when leaving
poll, and each poll call's timeout remains up to date:
09:41:16.270449 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10223556}) = 0
09:41:16.270457 epoll_wait(3, [], 200, 999) = 0
09:41:17.270130 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10238572}) = 0
09:41:17.270157 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:41:17.270194 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:41:17.270204 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:41:17.270216 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:41:17.270224 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:41:17.270299 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:41:17.270314 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10337841}) = 0
09:41:17.270323 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:41:17.270332 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10341860}) = 0
09:41:17.270340 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:41:17.270367 close(7) = 0
This may be backported to 2.1 and 2.0 though it's unlikely to bring any
user-visible improvement except to clarify debugging.
2019-12-11 02:12:23 -05:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Checks the next timer for the current thread by looking into its own timer
|
|
|
|
|
* list and the global one. It may return TICK_ETERNITY if no timer is present.
|
2020-04-16 14:51:34 -04:00
|
|
|
* Note that the next timer might very well be slightly in the past.
|
MINOR: tasks: split wake_expired_tasks() in two parts to avoid useless wakeups
We used to have wake_expired_tasks() wake up tasks and return the next
expiration delay. The problem this causes is that we have to call it just
before poll() in order to consider latest timers, but this also means that
we don't wake up all newly expired tasks upon return from poll(), which
thus systematically requires a second poll() round.
This is visible when running any scheduled task like a health check, as there
are systematically two poll() calls, one with the interval, nothing is done
after it, and another one with a zero delay, and the task is called:
listen test
bind *:8001
server s1 127.0.0.1:1111 check
09:37:38.200959 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8696843}) = 0
09:37:38.200967 epoll_wait(3, [], 200, 1000) = 0
09:37:39.202459 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8712467}) = 0
>> nothing run here, as the expired task was not woken up yet.
09:37:39.202497 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8715766}) = 0
09:37:39.202505 epoll_wait(3, [], 200, 0) = 0
09:37:39.202513 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8719064}) = 0
>> now the expired task was woken up
09:37:39.202522 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:37:39.202537 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:37:39.202565 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:37:39.202577 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:37:39.202585 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:37:39.202659 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:37:39.202673 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8814713}) = 0
09:37:39.202683 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:37:39.202693 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8818617}) = 0
09:37:39.202701 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:37:39.202715 close(7) = 0
Let's instead split the function in two parts:
- the first part, wake_expired_tasks(), called just before
process_runnable_tasks(), wakes up all expired tasks; it doesn't
compute any timeout.
- the second part, next_timer_expiry(), called just before poll(),
only computes the next timeout for the current thread.
Thanks to this, all expired tasks are properly woken up when leaving
poll, and each poll call's timeout remains up to date:
09:41:16.270449 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10223556}) = 0
09:41:16.270457 epoll_wait(3, [], 200, 999) = 0
09:41:17.270130 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10238572}) = 0
09:41:17.270157 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:41:17.270194 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:41:17.270204 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:41:17.270216 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:41:17.270224 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:41:17.270299 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:41:17.270314 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10337841}) = 0
09:41:17.270323 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:41:17.270332 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10341860}) = 0
09:41:17.270340 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:41:17.270367 close(7) = 0
This may be backported to 2.1 and 2.0 though it's unlikely to bring any
user-visible improvement except to clarify debugging.
2019-12-11 02:12:23 -05:00
|
|
|
*/
|
|
|
|
|
int next_timer_expiry()
|
|
|
|
|
{
|
2021-10-01 05:30:33 -04:00
|
|
|
struct thread_ctx * const tt = th_ctx; // thread's tasks
|
MINOR: tasks: split wake_expired_tasks() in two parts to avoid useless wakeups
We used to have wake_expired_tasks() wake up tasks and return the next
expiration delay. The problem this causes is that we have to call it just
before poll() in order to consider latest timers, but this also means that
we don't wake up all newly expired tasks upon return from poll(), which
thus systematically requires a second poll() round.
This is visible when running any scheduled task like a health check, as there
are systematically two poll() calls, one with the interval, nothing is done
after it, and another one with a zero delay, and the task is called:
listen test
bind *:8001
server s1 127.0.0.1:1111 check
09:37:38.200959 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8696843}) = 0
09:37:38.200967 epoll_wait(3, [], 200, 1000) = 0
09:37:39.202459 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8712467}) = 0
>> nothing run here, as the expired task was not woken up yet.
09:37:39.202497 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8715766}) = 0
09:37:39.202505 epoll_wait(3, [], 200, 0) = 0
09:37:39.202513 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8719064}) = 0
>> now the expired task was woken up
09:37:39.202522 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:37:39.202537 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:37:39.202565 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:37:39.202577 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:37:39.202585 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:37:39.202659 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:37:39.202673 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8814713}) = 0
09:37:39.202683 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:37:39.202693 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8818617}) = 0
09:37:39.202701 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:37:39.202715 close(7) = 0
Let's instead split the function in two parts:
- the first part, wake_expired_tasks(), called just before
process_runnable_tasks(), wakes up all expired tasks; it doesn't
compute any timeout.
- the second part, next_timer_expiry(), called just before poll(),
only computes the next timeout for the current thread.
Thanks to this, all expired tasks are properly woken up when leaving
poll, and each poll call's timeout remains up to date:
09:41:16.270449 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10223556}) = 0
09:41:16.270457 epoll_wait(3, [], 200, 999) = 0
09:41:17.270130 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10238572}) = 0
09:41:17.270157 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:41:17.270194 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:41:17.270204 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:41:17.270216 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:41:17.270224 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:41:17.270299 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:41:17.270314 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10337841}) = 0
09:41:17.270323 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:41:17.270332 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10341860}) = 0
09:41:17.270340 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:41:17.270367 close(7) = 0
This may be backported to 2.1 and 2.0 though it's unlikely to bring any
user-visible improvement except to clarify debugging.
2019-12-11 02:12:23 -05:00
|
|
|
struct eb32_node *eb;
|
|
|
|
|
int ret = TICK_ETERNITY;
|
2020-08-20 23:48:34 -04:00
|
|
|
__decl_thread(int key = TICK_ETERNITY);
|
MINOR: tasks: split wake_expired_tasks() in two parts to avoid useless wakeups
We used to have wake_expired_tasks() wake up tasks and return the next
expiration delay. The problem this causes is that we have to call it just
before poll() in order to consider latest timers, but this also means that
we don't wake up all newly expired tasks upon return from poll(), which
thus systematically requires a second poll() round.
This is visible when running any scheduled task like a health check, as there
are systematically two poll() calls, one with the interval, nothing is done
after it, and another one with a zero delay, and the task is called:
listen test
bind *:8001
server s1 127.0.0.1:1111 check
09:37:38.200959 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8696843}) = 0
09:37:38.200967 epoll_wait(3, [], 200, 1000) = 0
09:37:39.202459 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8712467}) = 0
>> nothing run here, as the expired task was not woken up yet.
09:37:39.202497 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8715766}) = 0
09:37:39.202505 epoll_wait(3, [], 200, 0) = 0
09:37:39.202513 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8719064}) = 0
>> now the expired task was woken up
09:37:39.202522 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:37:39.202537 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:37:39.202565 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:37:39.202577 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:37:39.202585 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:37:39.202659 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:37:39.202673 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8814713}) = 0
09:37:39.202683 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:37:39.202693 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=8818617}) = 0
09:37:39.202701 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:37:39.202715 close(7) = 0
Let's instead split the function in two parts:
- the first part, wake_expired_tasks(), called just before
process_runnable_tasks(), wakes up all expired tasks; it doesn't
compute any timeout.
- the second part, next_timer_expiry(), called just before poll(),
only computes the next timeout for the current thread.
Thanks to this, all expired tasks are properly woken up when leaving
poll, and each poll call's timeout remains up to date:
09:41:16.270449 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10223556}) = 0
09:41:16.270457 epoll_wait(3, [], 200, 999) = 0
09:41:17.270130 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10238572}) = 0
09:41:17.270157 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
09:41:17.270194 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
09:41:17.270204 setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
09:41:17.270216 setsockopt(7, SOL_TCP, TCP_QUICKACK, [0], 4) = 0
09:41:17.270224 connect(7, {sa_family=AF_INET, sin_port=htons(1111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
09:41:17.270299 epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLOUT, {u32=7, u64=7}}) = 0
09:41:17.270314 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10337841}) = 0
09:41:17.270323 epoll_wait(3, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=7, u64=7}}], 200, 1000) = 1
09:41:17.270332 clock_gettime(CLOCK_THREAD_CPUTIME_ID, {tv_sec=0, tv_nsec=10341860}) = 0
09:41:17.270340 getsockopt(7, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
09:41:17.270367 close(7) = 0
This may be backported to 2.1 and 2.0 though it's unlikely to bring any
user-visible improvement except to clarify debugging.
2019-12-11 02:12:23 -05:00
|
|
|
|
|
|
|
|
/* first check in the thread-local timers */
|
|
|
|
|
eb = eb32_lookup_ge(&tt->timers, now_ms - TIMER_LOOK_BACK);
|
|
|
|
|
if (!eb) {
|
|
|
|
|
/* we might have reached the end of the tree, typically because
|
|
|
|
|
* <now_ms> is in the first half and we're first scanning the last
|
|
|
|
|
* half. Let's loop back to the beginning of the tree now.
|
|
|
|
|
*/
|
|
|
|
|
eb = eb32_first(&tt->timers);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (eb)
|
|
|
|
|
ret = eb->key;
|
|
|
|
|
|
|
|
|
|
#ifdef USE_THREAD
|
|
|
|
|
if (!eb_is_empty(&timers)) {
|
|
|
|
|
HA_RWLOCK_RDLOCK(TASK_WQ_LOCK, &wq_lock);
|
|
|
|
|
eb = eb32_lookup_ge(&timers, now_ms - TIMER_LOOK_BACK);
|
|
|
|
|
if (!eb)
|
|
|
|
|
eb = eb32_first(&timers);
|
|
|
|
|
if (eb)
|
|
|
|
|
key = eb->key;
|
|
|
|
|
HA_RWLOCK_RDUNLOCK(TASK_WQ_LOCK, &wq_lock);
|
|
|
|
|
if (eb)
|
|
|
|
|
ret = tick_first(ret, key);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2017-11-05 13:09:27 -05:00
|
|
|
return ret;
|
2006-06-25 20:48:02 -04:00
|
|
|
}
|
|
|
|
|
|
2021-10-01 05:30:33 -04:00
|
|
|
/* Walks over tasklet lists th_ctx->tasklets[0..TL_CLASSES-1] and run at most
|
2020-06-24 04:17:29 -04:00
|
|
|
* budget[TL_*] of them. Returns the number of entries effectively processed
|
|
|
|
|
* (tasks and tasklets merged). The count of tasks in the list for the current
|
|
|
|
|
* thread is adjusted.
|
2020-01-30 12:13:13 -05:00
|
|
|
*/
|
2020-06-24 04:17:29 -04:00
|
|
|
unsigned int run_tasks_from_lists(unsigned int budgets[])
|
2020-01-30 12:13:13 -05:00
|
|
|
{
|
2021-03-02 10:09:26 -05:00
|
|
|
struct task *(*process)(struct task *t, void *ctx, unsigned int state);
|
2021-10-01 05:30:33 -04:00
|
|
|
struct list *tl_queues = th_ctx->tasklets;
|
2020-01-30 12:13:13 -05:00
|
|
|
struct task *t;
|
2020-06-24 05:11:02 -04:00
|
|
|
uint8_t budget_mask = (1 << TL_CLASSES) - 1;
|
2021-01-28 18:07:40 -05:00
|
|
|
struct sched_activity *profile_entry = NULL;
|
2020-06-24 04:17:29 -04:00
|
|
|
unsigned int done = 0;
|
|
|
|
|
unsigned int queue;
|
2021-03-02 10:09:26 -05:00
|
|
|
unsigned int state;
|
2020-01-30 12:13:13 -05:00
|
|
|
void *ctx;
|
|
|
|
|
|
2020-06-24 04:17:29 -04:00
|
|
|
for (queue = 0; queue < TL_CLASSES;) {
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current_queue = queue;
|
2020-06-24 04:17:29 -04:00
|
|
|
|
2020-06-24 05:11:02 -04:00
|
|
|
/* global.tune.sched.low-latency is set */
|
|
|
|
|
if (global.tune.options & GTUNE_SCHED_LOW_LATENCY) {
|
2021-10-01 05:30:33 -04:00
|
|
|
if (unlikely(th_ctx->tl_class_mask & budget_mask & ((1 << queue) - 1))) {
|
2020-06-24 05:11:02 -04:00
|
|
|
/* a lower queue index has tasks again and still has a
|
|
|
|
|
* budget to run them. Let's switch to it now.
|
|
|
|
|
*/
|
2021-10-01 05:30:33 -04:00
|
|
|
queue = (th_ctx->tl_class_mask & 1) ? 0 :
|
|
|
|
|
(th_ctx->tl_class_mask & 2) ? 1 : 2;
|
2020-06-24 05:11:02 -04:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (unlikely(queue > TL_URGENT &&
|
|
|
|
|
budget_mask & (1 << TL_URGENT) &&
|
2021-10-01 05:30:33 -04:00
|
|
|
!MT_LIST_ISEMPTY(&th_ctx->shared_tasklet_list))) {
|
2020-06-24 05:11:02 -04:00
|
|
|
/* an urgent tasklet arrived from another thread */
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (unlikely(queue > TL_NORMAL &&
|
|
|
|
|
budget_mask & (1 << TL_NORMAL) &&
|
2021-10-01 05:30:33 -04:00
|
|
|
(!eb_is_empty(&th_ctx->rqueue) ||
|
2020-06-24 05:11:02 -04:00
|
|
|
(global_tasks_mask & tid_bit)))) {
|
|
|
|
|
/* a task was woken up by a bulk tasklet or another thread */
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-24 03:54:24 -04:00
|
|
|
if (LIST_ISEMPTY(&tl_queues[queue])) {
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->tl_class_mask &= ~(1 << queue);
|
2020-06-24 04:17:29 -04:00
|
|
|
queue++;
|
|
|
|
|
continue;
|
2020-06-24 03:54:24 -04:00
|
|
|
}
|
|
|
|
|
|
2020-06-24 04:17:29 -04:00
|
|
|
if (!budgets[queue]) {
|
2020-06-24 05:11:02 -04:00
|
|
|
budget_mask &= ~(1 << queue);
|
2020-06-24 04:17:29 -04:00
|
|
|
queue++;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2020-06-24 03:54:24 -04:00
|
|
|
|
2020-06-24 04:17:29 -04:00
|
|
|
budgets[queue]--;
|
2020-01-30 12:13:13 -05:00
|
|
|
activity[tid].ctxsw++;
|
2021-10-21 10:17:29 -04:00
|
|
|
|
|
|
|
|
t = (struct task *)LIST_ELEM(tl_queues[queue].n, struct tasklet *, list);
|
2020-01-30 12:13:13 -05:00
|
|
|
ctx = t->context;
|
|
|
|
|
process = t->process;
|
|
|
|
|
t->calls++;
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current = t;
|
2021-10-21 10:17:29 -04:00
|
|
|
th_ctx->flags &= ~TH_FL_STUCK; // this thread is still running
|
2020-01-30 12:13:13 -05:00
|
|
|
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_DEC(&th_ctx->rq_total);
|
2020-11-30 08:52:11 -05:00
|
|
|
|
2021-10-21 10:17:29 -04:00
|
|
|
if (t->state & TASK_F_TASKLET) {
|
2021-02-25 03:32:58 -05:00
|
|
|
uint64_t before = 0;
|
|
|
|
|
|
BUG/MEDIUM: task: close a possible data race condition on a tasklet's list link
In issue #958 Ashley Penney reported intermittent crashes on AWS's ARM
nodes which would not happen on x86 nodes. After investigation it turned
out that the Neoverse N1 CPU cores used in the Graviton2 CPU are much
more aggressive than the usual Cortex A53/A72/A55 or any x86 regarding
memory ordering.
The issue that was triggered there is that if a tasklet_wakeup() call
is made on a tasklet scheduled to run on a foreign thread and that
tasklet is just being dequeued to be processed, there can be a race at
two places:
- if MT_LIST_TRY_ADDQ() happens between MT_LIST_BEHEAD() and
LIST_SPLICE_END_DETACHED() if the tasklet is alone in the list,
because the emptiness tests matches ;
- if MT_LIST_TRY_ADDQ() happens during LIST_DEL_INIT() in
run_tasks_from_lists(), then depending on how LIST_DEL_INIT() ends
up being implemented, it may even corrupt the adjacent nodes while
they're being reused for the in-tree storage.
This issue was introduced in 2.2 when support for waking up remote
tasklets was added. Initially the attachment of a tasklet to a list
was enough to know its status and this used to be stable information.
Now it's not sufficient to rely on this anymore, thus we need to use
a different information.
This patch solves this by adding a new task flag, TASK_IN_LIST, which
is atomically set before attaching a tasklet to a list, and is only
removed after the tasklet is detached from a list. It is checked
by tasklet_wakeup_on() so that it may only be done while the tasklet
is out of any list, and is cleared during the state switch when calling
the tasklet. Note that the flag is not set for pure tasks as it's not
needed.
However this introduces a new special case: the function
tasklet_remove_from_tasklet_list() needs to keep both states in sync
and cannot check both the state and the attachment to a list at the
same time. This function is already limited to being used by the thread
owning the tasklet, so in this case the test remains reliable. However,
just like its predecessors, this function is wrong by design and it
should probably be replaced with a stricter one, a lazy one, or be
totally removed (it's only used in checks to avoid calling a possibly
scheduled event, and when freeing a tasklet). Regardless, for now the
function exists so the flag is removed only if the deletion could be
done, which covers all cases we're interested in regarding the insertion.
This removal is safe against a concurrent tasklet_wakeup_on() since
MT_LIST_DEL() guarantees the atomic test, and will ultimately clear
the flag only if the task could be deleted, so the flag will always
reflect the last state.
This should be carefully be backported as far as 2.2 after some
observation period. This patch depends on previous patch
"MINOR: task: remove __tasklet_remove_from_tasklet_list()".
2020-11-30 08:58:53 -05:00
|
|
|
LIST_DEL_INIT(&((struct tasklet *)t)->list);
|
|
|
|
|
__ha_barrier_store();
|
2021-01-28 18:07:40 -05:00
|
|
|
|
|
|
|
|
if (unlikely(task_profiling_mask & tid_bit)) {
|
|
|
|
|
profile_entry = sched_activity_entry(sched_activity, t->process);
|
|
|
|
|
before = now_mono_time();
|
2021-02-25 02:39:07 -05:00
|
|
|
#ifdef DEBUG_TASK
|
2021-02-25 03:32:58 -05:00
|
|
|
if (((struct tasklet *)t)->call_date) {
|
|
|
|
|
HA_ATOMIC_ADD(&profile_entry->lat_time, before - ((struct tasklet *)t)->call_date);
|
|
|
|
|
((struct tasklet *)t)->call_date = 0;
|
|
|
|
|
}
|
2021-02-25 02:39:07 -05:00
|
|
|
#endif
|
2021-02-25 03:32:58 -05:00
|
|
|
}
|
|
|
|
|
|
2021-10-21 10:17:29 -04:00
|
|
|
state = _HA_ATOMIC_FETCH_AND(&t->state, TASK_PERSISTENT);
|
2021-02-25 03:32:58 -05:00
|
|
|
__ha_barrier_atomic_store();
|
|
|
|
|
|
2021-07-28 10:12:57 -04:00
|
|
|
if (likely(!(state & TASK_KILLED))) {
|
|
|
|
|
process(t, ctx, state);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
done++;
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current = NULL;
|
2021-07-28 10:12:57 -04:00
|
|
|
pool_free(pool_head_tasklet, t);
|
|
|
|
|
__ha_barrier_store();
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2021-02-25 03:32:58 -05:00
|
|
|
|
|
|
|
|
if (unlikely(task_profiling_mask & tid_bit)) {
|
2021-04-06 07:53:36 -04:00
|
|
|
HA_ATOMIC_INC(&profile_entry->calls);
|
2021-01-28 18:07:40 -05:00
|
|
|
HA_ATOMIC_ADD(&profile_entry->cpu_time, now_mono_time() - before);
|
|
|
|
|
}
|
2021-02-25 03:32:58 -05:00
|
|
|
|
2020-01-30 12:13:13 -05:00
|
|
|
done++;
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current = NULL;
|
2020-01-31 04:39:03 -05:00
|
|
|
__ha_barrier_store();
|
2020-01-30 12:13:13 -05:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
BUG/MEDIUM: task: close a possible data race condition on a tasklet's list link
In issue #958 Ashley Penney reported intermittent crashes on AWS's ARM
nodes which would not happen on x86 nodes. After investigation it turned
out that the Neoverse N1 CPU cores used in the Graviton2 CPU are much
more aggressive than the usual Cortex A53/A72/A55 or any x86 regarding
memory ordering.
The issue that was triggered there is that if a tasklet_wakeup() call
is made on a tasklet scheduled to run on a foreign thread and that
tasklet is just being dequeued to be processed, there can be a race at
two places:
- if MT_LIST_TRY_ADDQ() happens between MT_LIST_BEHEAD() and
LIST_SPLICE_END_DETACHED() if the tasklet is alone in the list,
because the emptiness tests matches ;
- if MT_LIST_TRY_ADDQ() happens during LIST_DEL_INIT() in
run_tasks_from_lists(), then depending on how LIST_DEL_INIT() ends
up being implemented, it may even corrupt the adjacent nodes while
they're being reused for the in-tree storage.
This issue was introduced in 2.2 when support for waking up remote
tasklets was added. Initially the attachment of a tasklet to a list
was enough to know its status and this used to be stable information.
Now it's not sufficient to rely on this anymore, thus we need to use
a different information.
This patch solves this by adding a new task flag, TASK_IN_LIST, which
is atomically set before attaching a tasklet to a list, and is only
removed after the tasklet is detached from a list. It is checked
by tasklet_wakeup_on() so that it may only be done while the tasklet
is out of any list, and is cleared during the state switch when calling
the tasklet. Note that the flag is not set for pure tasks as it's not
needed.
However this introduces a new special case: the function
tasklet_remove_from_tasklet_list() needs to keep both states in sync
and cannot check both the state and the attachment to a list at the
same time. This function is already limited to being used by the thread
owning the tasklet, so in this case the test remains reliable. However,
just like its predecessors, this function is wrong by design and it
should probably be replaced with a stricter one, a lazy one, or be
totally removed (it's only used in checks to avoid calling a possibly
scheduled event, and when freeing a tasklet). Regardless, for now the
function exists so the flag is removed only if the deletion could be
done, which covers all cases we're interested in regarding the insertion.
This removal is safe against a concurrent tasklet_wakeup_on() since
MT_LIST_DEL() guarantees the atomic test, and will ultimately clear
the flag only if the task could be deleted, so the flag will always
reflect the last state.
This should be carefully be backported as far as 2.2 after some
observation period. This patch depends on previous patch
"MINOR: task: remove __tasklet_remove_from_tasklet_list()".
2020-11-30 08:58:53 -05:00
|
|
|
LIST_DEL_INIT(&((struct tasklet *)t)->list);
|
|
|
|
|
__ha_barrier_store();
|
2021-10-21 10:17:29 -04:00
|
|
|
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
/* We must be the exclusive owner of the TASK_RUNNING bit, and
|
|
|
|
|
* have to be careful that the task is not being manipulated on
|
|
|
|
|
* another thread finding it expired in wake_expired_tasks().
|
|
|
|
|
* The TASK_RUNNING bit will be set during these operations,
|
|
|
|
|
* they are extremely rare and do not last long so the best to
|
|
|
|
|
* do here is to wait.
|
|
|
|
|
*/
|
|
|
|
|
state = _HA_ATOMIC_LOAD(&t->state);
|
|
|
|
|
do {
|
|
|
|
|
while (unlikely(state & TASK_RUNNING)) {
|
|
|
|
|
__ha_cpu_relax();
|
|
|
|
|
state = _HA_ATOMIC_LOAD(&t->state);
|
|
|
|
|
}
|
|
|
|
|
} while (!_HA_ATOMIC_CAS(&t->state, &state, (state & TASK_PERSISTENT) | TASK_RUNNING));
|
2021-10-21 10:17:29 -04:00
|
|
|
|
2020-01-31 10:39:30 -05:00
|
|
|
__ha_barrier_atomic_store();
|
|
|
|
|
|
2020-01-30 12:13:13 -05:00
|
|
|
/* OK then this is a regular task */
|
|
|
|
|
|
2021-10-01 05:30:33 -04:00
|
|
|
_HA_ATOMIC_DEC(&ha_thread_ctx[tid].tasks_in_list);
|
2020-01-30 12:13:13 -05:00
|
|
|
if (unlikely(t->call_date)) {
|
|
|
|
|
uint64_t now_ns = now_mono_time();
|
2021-01-28 18:07:40 -05:00
|
|
|
uint64_t lat = now_ns - t->call_date;
|
2020-01-30 12:13:13 -05:00
|
|
|
|
2021-01-28 18:07:40 -05:00
|
|
|
t->lat_time += lat;
|
2020-01-30 12:13:13 -05:00
|
|
|
t->call_date = now_ns;
|
2021-01-28 18:07:40 -05:00
|
|
|
profile_entry = sched_activity_entry(sched_activity, t->process);
|
|
|
|
|
HA_ATOMIC_ADD(&profile_entry->lat_time, lat);
|
2021-04-06 07:53:36 -04:00
|
|
|
HA_ATOMIC_INC(&profile_entry->calls);
|
2020-01-30 12:13:13 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
__ha_barrier_store();
|
2020-06-30 05:48:48 -04:00
|
|
|
|
|
|
|
|
/* Note for below: if TASK_KILLED arrived before we've read the state, we
|
|
|
|
|
* directly free the task. Otherwise it will be seen after processing and
|
|
|
|
|
* it's freed on the exit path.
|
|
|
|
|
*/
|
|
|
|
|
if (likely(!(state & TASK_KILLED) && process == process_stream))
|
2020-01-30 12:13:13 -05:00
|
|
|
t = process_stream(t, ctx, state);
|
2020-06-30 05:48:48 -04:00
|
|
|
else if (!(state & TASK_KILLED) && process != NULL)
|
2020-01-30 12:13:13 -05:00
|
|
|
t = process(t, ctx, state);
|
|
|
|
|
else {
|
2020-07-17 08:37:51 -04:00
|
|
|
task_unlink_wq(t);
|
2020-01-30 12:13:13 -05:00
|
|
|
__task_free(t);
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current = NULL;
|
2020-01-30 12:13:13 -05:00
|
|
|
__ha_barrier_store();
|
|
|
|
|
/* We don't want max_processed to be decremented if
|
|
|
|
|
* we're just freeing a destroyed task, we should only
|
|
|
|
|
* do so if we really ran a task.
|
|
|
|
|
*/
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current = NULL;
|
2020-01-30 12:13:13 -05:00
|
|
|
__ha_barrier_store();
|
|
|
|
|
/* If there is a pending state we have to wake up the task
|
|
|
|
|
* immediately, else we defer it into wait queue
|
|
|
|
|
*/
|
|
|
|
|
if (t != NULL) {
|
|
|
|
|
if (unlikely(t->call_date)) {
|
2021-01-28 18:07:40 -05:00
|
|
|
uint64_t cpu = now_mono_time() - t->call_date;
|
|
|
|
|
|
|
|
|
|
t->cpu_time += cpu;
|
2020-01-30 12:13:13 -05:00
|
|
|
t->call_date = 0;
|
2021-01-28 18:07:40 -05:00
|
|
|
HA_ATOMIC_ADD(&profile_entry->cpu_time, cpu);
|
2020-01-30 12:13:13 -05:00
|
|
|
}
|
|
|
|
|
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
state = _HA_ATOMIC_LOAD(&t->state);
|
2020-06-30 05:48:48 -04:00
|
|
|
if (unlikely(state & TASK_KILLED)) {
|
2020-07-17 08:37:51 -04:00
|
|
|
task_unlink_wq(t);
|
2020-06-30 05:48:48 -04:00
|
|
|
__task_free(t);
|
|
|
|
|
}
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
else {
|
2020-01-30 12:13:13 -05:00
|
|
|
task_queue(t);
|
BUG/MAJOR: sched: prevent rare concurrent wakeup of multi-threaded tasks
Since the relaxation of the run-queue locks in 2.0 there has been a
very small but existing race between expired tasks and running tasks:
a task might be expiring and being woken up at the same time, on
different threads. This is protected against via the TASK_QUEUED and
TASK_RUNNING flags, but just after the task finishes executing, it
releases it TASK_RUNNING bit an only then it may go to task_queue().
This one will do nothing if the task's ->expire field is zero, but
if the field turns to zero between this test and the call to
__task_queue() then three things may happen:
- the task may remain in the WQ until the 24 next days if it's in
the future;
- the task may prevent any other task after it from expiring during
the 24 next days once it's queued
- if DEBUG_STRICT is set on 2.4 and above, an abort may happen
- since 2.2, if the task got killed in between, then we may
even requeue a freed task, causing random behaviour next time
it's found there, or possibly corrupting the tree if it gets
reinserted later.
The peers code is one call path that easily reproduces the case with
the ->expire field being reset, because it starts by setting it to
TICK_ETERNITY as the first thing when entering the task handler. But
other code parts also use multi-threaded tasks and rightfully expect
to be able to touch their expire field without causing trouble. No
trivial code path was found that would destroy such a shared task at
runtime, which already limits the risks.
This must be backported to 2.0.
2022-02-14 04:18:51 -05:00
|
|
|
task_drop_running(t, 0);
|
|
|
|
|
}
|
2020-01-30 12:13:13 -05:00
|
|
|
}
|
|
|
|
|
done++;
|
|
|
|
|
}
|
2021-10-01 05:30:33 -04:00
|
|
|
th_ctx->current_queue = -1;
|
2020-06-23 10:35:38 -04:00
|
|
|
|
2020-01-30 12:13:13 -05:00
|
|
|
return done;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-29 16:40:23 -04:00
|
|
|
/* The run queue is chronologically sorted in a tree. An insertion counter is
|
|
|
|
|
* used to assign a position to each task. This counter may be combined with
|
|
|
|
|
* other variables (eg: nice value) to set the final position in the tree. The
|
|
|
|
|
* counter may wrap without a problem, of course. We then limit the number of
|
2017-11-14 04:38:36 -05:00
|
|
|
* tasks processed to 200 in any case, so that general latency remains low and
|
2019-04-12 12:03:41 -04:00
|
|
|
* so that task positions have a chance to be considered. The function scans
|
|
|
|
|
* both the global and local run queues and picks the most urgent task between
|
|
|
|
|
* the two. We need to grab the global runqueue lock to touch it so it's taken
|
|
|
|
|
* on the very first access to the global run queue and is released as soon as
|
|
|
|
|
* it reaches the end.
|
2006-06-25 20:48:02 -04:00
|
|
|
*
|
2008-06-29 16:40:23 -04:00
|
|
|
* The function adjusts <next> if a new event is closer.
|
2006-06-25 20:48:02 -04:00
|
|
|
*/
|
2014-12-15 07:26:01 -05:00
|
|
|
void process_runnable_tasks()
|
2006-06-25 20:48:02 -04:00
|
|
|
{
|
2021-10-01 05:30:33 -04:00
|
|
|
struct thread_ctx * const tt = th_ctx;
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
struct eb32sc_node *lrq; // next local run queue entry
|
|
|
|
|
struct eb32sc_node *grq; // next global run queue entry
|
2007-01-06 18:38:00 -05:00
|
|
|
struct task *t;
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
const unsigned int default_weights[TL_CLASSES] = {
|
|
|
|
|
[TL_URGENT] = 64, // ~50% of CPU bandwidth for I/O
|
|
|
|
|
[TL_NORMAL] = 48, // ~37% of CPU bandwidth for tasks
|
|
|
|
|
[TL_BULK] = 16, // ~13% of CPU bandwidth for self-wakers
|
2021-02-26 03:16:22 -05:00
|
|
|
[TL_HEAVY] = 1, // never more than 1 heavy task at once
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
};
|
|
|
|
|
unsigned int max[TL_CLASSES]; // max to be run per class
|
|
|
|
|
unsigned int max_total; // sum of max above
|
2019-10-11 10:35:01 -04:00
|
|
|
struct mt_list *tmp_list;
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
unsigned int queue;
|
|
|
|
|
int max_processed;
|
2021-02-25 01:09:08 -05:00
|
|
|
int lpicked, gpicked;
|
2021-02-26 04:18:11 -05:00
|
|
|
int heavy_queued = 0;
|
2020-11-30 09:39:00 -05:00
|
|
|
int budget;
|
2017-11-14 04:26:53 -05:00
|
|
|
|
2021-09-30 12:48:37 -04:00
|
|
|
th_ctx->flags &= ~TH_FL_STUCK; // this thread is still running
|
2019-05-22 01:06:44 -04:00
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
if (!thread_has_tasks()) {
|
|
|
|
|
activity[tid].empty_rq++;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
MEDIUM: tasks: also process late wakeups in process_runnable_tasks()
Since version 1.8, we've started to use tasks and tasklets more
extensively to defer I/O processing. Originally with the simple
scheduler, a task waking another one up using task_wakeup() would
have caused it to be processed right after the list of runnable ones.
With the introduction of tasklets, we've started to spill running
tasks from the run queues to the tasklet queues, so if a task wakes
another one up, it will only be executed on the next call to
process_runnable_task(), which means after yet another round of
polling loop.
This is particularly visible with I/Os hitting muxes: poll() reports
a read event, the connection layer performs a tasklet_wakeup() on the
mux subscribed to this I/O, and this mux in turn signals the upper
layer stream using task_wakeup(). The process goes back to poll() with
a null timeout since there's one active task, then back to checking all
possibly expired events, and finally back to process_runnable_tasks()
again. Worse, when there is high I/O activity, doing so will make the
task's execution further apart from the tasklet and will both increase
the total processing latency and reduce the cache hit ratio.
This patch brings back to the original spirit of process_runnable_tasks()
which is to execute runnable tasks as long as the execution budget is not
exhausted. By doing so, we're immediately cutting in half the number of
calls to all functions called by run_poll_loop(), and halving the number
of calls to poll(). Furthermore, calling poll() less often also means
purging FD updates less often and offering more chances to merge them.
This also has the nice effect of making tune.runqueue-depth effective
again, as in the past it used to be quickly bounded by this artificial
event horizon which was preventing from executing remaining tasks. On
certain workloads we can see a 2-3% performance increase.
2020-06-19 06:17:55 -04:00
|
|
|
max_processed = global.tune.runqueue_depth;
|
|
|
|
|
|
|
|
|
|
if (likely(niced_tasks))
|
|
|
|
|
max_processed = (max_processed + 3) / 4;
|
|
|
|
|
|
2021-10-01 05:30:33 -04:00
|
|
|
if (max_processed < th_ctx->rq_total && th_ctx->rq_total <= 2*max_processed) {
|
2021-03-10 03:26:24 -05:00
|
|
|
/* If the run queue exceeds the budget by up to 50%, let's cut it
|
|
|
|
|
* into two identical halves to improve latency.
|
|
|
|
|
*/
|
2021-10-01 05:30:33 -04:00
|
|
|
max_processed = th_ctx->rq_total / 2;
|
2021-03-10 03:26:24 -05:00
|
|
|
}
|
|
|
|
|
|
MEDIUM: tasks: also process late wakeups in process_runnable_tasks()
Since version 1.8, we've started to use tasks and tasklets more
extensively to defer I/O processing. Originally with the simple
scheduler, a task waking another one up using task_wakeup() would
have caused it to be processed right after the list of runnable ones.
With the introduction of tasklets, we've started to spill running
tasks from the run queues to the tasklet queues, so if a task wakes
another one up, it will only be executed on the next call to
process_runnable_task(), which means after yet another round of
polling loop.
This is particularly visible with I/Os hitting muxes: poll() reports
a read event, the connection layer performs a tasklet_wakeup() on the
mux subscribed to this I/O, and this mux in turn signals the upper
layer stream using task_wakeup(). The process goes back to poll() with
a null timeout since there's one active task, then back to checking all
possibly expired events, and finally back to process_runnable_tasks()
again. Worse, when there is high I/O activity, doing so will make the
task's execution further apart from the tasklet and will both increase
the total processing latency and reduce the cache hit ratio.
This patch brings back to the original spirit of process_runnable_tasks()
which is to execute runnable tasks as long as the execution budget is not
exhausted. By doing so, we're immediately cutting in half the number of
calls to all functions called by run_poll_loop(), and halving the number
of calls to poll(). Furthermore, calling poll() less often also means
purging FD updates less often and offering more chances to merge them.
This also has the nice effect of making tune.runqueue-depth effective
again, as in the past it used to be quickly bounded by this artificial
event horizon which was preventing from executing remaining tasks. On
certain workloads we can see a 2-3% performance increase.
2020-06-19 06:17:55 -04:00
|
|
|
not_done_yet:
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
max[TL_URGENT] = max[TL_NORMAL] = max[TL_BULK] = 0;
|
|
|
|
|
|
|
|
|
|
/* urgent tasklets list gets a default weight of ~50% */
|
2020-06-24 03:39:48 -04:00
|
|
|
if ((tt->tl_class_mask & (1 << TL_URGENT)) ||
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
!MT_LIST_ISEMPTY(&tt->shared_tasklet_list))
|
|
|
|
|
max[TL_URGENT] = default_weights[TL_URGENT];
|
|
|
|
|
|
|
|
|
|
/* normal tasklets list gets a default weight of ~37% */
|
2020-06-24 03:39:48 -04:00
|
|
|
if ((tt->tl_class_mask & (1 << TL_NORMAL)) ||
|
2021-10-01 05:30:33 -04:00
|
|
|
!eb_is_empty(&th_ctx->rqueue) || (global_tasks_mask & tid_bit))
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
max[TL_NORMAL] = default_weights[TL_NORMAL];
|
|
|
|
|
|
|
|
|
|
/* bulk tasklets list gets a default weight of ~13% */
|
2020-06-24 03:39:48 -04:00
|
|
|
if ((tt->tl_class_mask & (1 << TL_BULK)))
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
max[TL_BULK] = default_weights[TL_BULK];
|
|
|
|
|
|
2021-02-26 03:16:22 -05:00
|
|
|
/* heavy tasks are processed only once and never refilled in a
|
2021-02-26 04:18:11 -05:00
|
|
|
* call round. That budget is not lost either as we don't reset
|
|
|
|
|
* it unless consumed.
|
2021-02-26 03:16:22 -05:00
|
|
|
*/
|
2021-02-26 04:18:11 -05:00
|
|
|
if (!heavy_queued) {
|
|
|
|
|
if ((tt->tl_class_mask & (1 << TL_HEAVY)))
|
|
|
|
|
max[TL_HEAVY] = default_weights[TL_HEAVY];
|
|
|
|
|
else
|
|
|
|
|
max[TL_HEAVY] = 0;
|
|
|
|
|
heavy_queued = 1;
|
|
|
|
|
}
|
2021-02-26 03:16:22 -05:00
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
/* Now compute a fair share of the weights. Total may slightly exceed
|
2020-06-30 07:46:21 -04:00
|
|
|
* 100% due to rounding, this is not a problem. Note that while in
|
|
|
|
|
* theory the sum cannot be NULL as we cannot get there without tasklets
|
|
|
|
|
* to process, in practice it seldom happens when multiple writers
|
2021-04-21 01:32:39 -04:00
|
|
|
* conflict and rollback on MT_LIST_TRY_APPEND(shared_tasklet_list), causing
|
2020-06-30 07:46:21 -04:00
|
|
|
* a first MT_LIST_ISEMPTY() to succeed for thread_has_task() and the
|
|
|
|
|
* one above to finally fail. This is extremely rare and not a problem.
|
2019-10-11 10:35:01 -04:00
|
|
|
*/
|
2021-02-26 03:16:22 -05:00
|
|
|
max_total = max[TL_URGENT] + max[TL_NORMAL] + max[TL_BULK] + max[TL_HEAVY];
|
2020-06-30 07:46:21 -04:00
|
|
|
if (!max_total)
|
|
|
|
|
return;
|
|
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
for (queue = 0; queue < TL_CLASSES; queue++)
|
|
|
|
|
max[queue] = ((unsigned)max_processed * max[queue] + max_total - 1) / max_total;
|
2019-04-12 12:03:41 -04:00
|
|
|
|
2021-02-26 04:18:11 -05:00
|
|
|
/* The heavy queue must never process more than one task at once
|
|
|
|
|
* anyway.
|
|
|
|
|
*/
|
|
|
|
|
if (max[TL_HEAVY] > 1)
|
|
|
|
|
max[TL_HEAVY] = 1;
|
|
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
lrq = grq = NULL;
|
2020-01-30 12:37:28 -05:00
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
/* pick up to max[TL_NORMAL] regular tasks from prio-ordered run queues */
|
2019-04-12 12:03:41 -04:00
|
|
|
/* Note: the grq lock is always held when grq is not null */
|
2021-02-25 01:09:08 -05:00
|
|
|
lpicked = gpicked = 0;
|
2021-02-24 08:13:40 -05:00
|
|
|
budget = max[TL_NORMAL] - tt->tasks_in_list;
|
2021-02-25 01:09:08 -05:00
|
|
|
while (lpicked + gpicked < budget) {
|
2019-04-12 12:03:41 -04:00
|
|
|
if ((global_tasks_mask & tid_bit) && !grq) {
|
2019-04-15 12:52:40 -04:00
|
|
|
#ifdef USE_THREAD
|
2019-04-12 12:03:41 -04:00
|
|
|
HA_SPIN_LOCK(TASK_RQ_LOCK, &rq_lock);
|
2021-02-20 06:49:54 -05:00
|
|
|
grq = eb32sc_lookup_ge(&rqueue, global_rqueue_ticks - TIMER_LOOK_BACK, tid_bit);
|
2019-04-12 12:03:41 -04:00
|
|
|
if (unlikely(!grq)) {
|
|
|
|
|
grq = eb32sc_first(&rqueue, tid_bit);
|
|
|
|
|
if (!grq) {
|
2019-04-17 13:10:22 -04:00
|
|
|
global_tasks_mask &= ~tid_bit;
|
2019-04-12 12:03:41 -04:00
|
|
|
HA_SPIN_UNLOCK(TASK_RQ_LOCK, &rq_lock);
|
2018-07-26 09:25:49 -04:00
|
|
|
}
|
2017-11-05 10:35:59 -05:00
|
|
|
}
|
2019-04-15 12:52:40 -04:00
|
|
|
#endif
|
2019-04-12 12:03:41 -04:00
|
|
|
}
|
2017-11-05 10:35:59 -05:00
|
|
|
|
2019-04-12 12:03:41 -04:00
|
|
|
/* If a global task is available for this thread, it's in grq
|
|
|
|
|
* now and the global RQ is locked.
|
|
|
|
|
*/
|
2018-05-18 12:38:23 -04:00
|
|
|
|
2019-04-12 12:03:41 -04:00
|
|
|
if (!lrq) {
|
2021-02-20 06:49:54 -05:00
|
|
|
lrq = eb32sc_lookup_ge(&tt->rqueue, tt->rqueue_ticks - TIMER_LOOK_BACK, tid_bit);
|
2019-04-12 12:03:41 -04:00
|
|
|
if (unlikely(!lrq))
|
2019-09-24 01:19:08 -04:00
|
|
|
lrq = eb32sc_first(&tt->rqueue, tid_bit);
|
2017-11-05 10:35:59 -05:00
|
|
|
}
|
|
|
|
|
|
2019-04-12 12:03:41 -04:00
|
|
|
if (!lrq && !grq)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (likely(!grq || (lrq && (int)(lrq->key - grq->key) <= 0))) {
|
|
|
|
|
t = eb32sc_entry(lrq, struct task, rq);
|
|
|
|
|
lrq = eb32sc_next(lrq, tid_bit);
|
2021-02-25 01:14:58 -05:00
|
|
|
eb32sc_delete(&t->rq);
|
2021-02-25 01:09:08 -05:00
|
|
|
lpicked++;
|
2018-05-18 12:38:23 -04:00
|
|
|
}
|
2019-04-15 12:52:40 -04:00
|
|
|
#ifdef USE_THREAD
|
2019-04-12 12:03:41 -04:00
|
|
|
else {
|
|
|
|
|
t = eb32sc_entry(grq, struct task, rq);
|
|
|
|
|
grq = eb32sc_next(grq, tid_bit);
|
2021-02-25 01:14:58 -05:00
|
|
|
_HA_ATOMIC_AND(&t->state, ~TASK_GLOBAL);
|
|
|
|
|
eb32sc_delete(&t->rq);
|
|
|
|
|
|
2019-04-12 12:03:41 -04:00
|
|
|
if (unlikely(!grq)) {
|
|
|
|
|
grq = eb32sc_first(&rqueue, tid_bit);
|
|
|
|
|
if (!grq) {
|
2019-04-17 13:10:22 -04:00
|
|
|
global_tasks_mask &= ~tid_bit;
|
2019-04-12 12:03:41 -04:00
|
|
|
HA_SPIN_UNLOCK(TASK_RQ_LOCK, &rq_lock);
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-02-25 01:09:08 -05:00
|
|
|
gpicked++;
|
2017-03-30 09:37:25 -04:00
|
|
|
}
|
2019-04-15 12:52:40 -04:00
|
|
|
#endif
|
2021-02-25 01:14:58 -05:00
|
|
|
if (t->nice)
|
2021-04-06 07:53:36 -04:00
|
|
|
_HA_ATOMIC_DEC(&niced_tasks);
|
2019-04-12 12:03:41 -04:00
|
|
|
|
2020-11-30 09:30:22 -05:00
|
|
|
/* Add it to the local task list */
|
2021-04-21 01:32:39 -04:00
|
|
|
LIST_APPEND(&tt->tasklets[TL_NORMAL], &((struct tasklet *)t)->list);
|
2018-05-18 12:45:28 -04:00
|
|
|
}
|
2019-04-12 12:03:41 -04:00
|
|
|
|
|
|
|
|
/* release the rqueue lock */
|
|
|
|
|
if (grq) {
|
|
|
|
|
HA_SPIN_UNLOCK(TASK_RQ_LOCK, &rq_lock);
|
|
|
|
|
grq = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-25 01:09:08 -05:00
|
|
|
if (lpicked + gpicked) {
|
2020-11-30 09:39:00 -05:00
|
|
|
tt->tl_class_mask |= 1 << TL_NORMAL;
|
2021-02-25 01:09:08 -05:00
|
|
|
_HA_ATOMIC_ADD(&tt->tasks_in_list, lpicked + gpicked);
|
2021-03-09 03:59:50 -05:00
|
|
|
#ifdef USE_THREAD
|
2021-02-25 01:51:18 -05:00
|
|
|
if (gpicked) {
|
|
|
|
|
_HA_ATOMIC_SUB(&grq_total, gpicked);
|
2021-02-25 01:19:45 -05:00
|
|
|
_HA_ATOMIC_ADD(&tt->rq_total, gpicked);
|
2021-02-25 01:51:18 -05:00
|
|
|
}
|
2021-03-09 03:59:50 -05:00
|
|
|
#endif
|
2021-02-25 01:09:08 -05:00
|
|
|
activity[tid].tasksw += lpicked + gpicked;
|
2020-11-30 09:39:00 -05:00
|
|
|
}
|
|
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
/* Merge the list of tasklets waken up by other threads to the
|
|
|
|
|
* main list.
|
|
|
|
|
*/
|
|
|
|
|
tmp_list = MT_LIST_BEHEAD(&tt->shared_tasklet_list);
|
2020-06-24 03:39:48 -04:00
|
|
|
if (tmp_list) {
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
LIST_SPLICE_END_DETACHED(&tt->tasklets[TL_URGENT], (struct list *)tmp_list);
|
2020-06-24 03:39:48 -04:00
|
|
|
if (!LIST_ISEMPTY(&tt->tasklets[TL_URGENT]))
|
|
|
|
|
tt->tl_class_mask |= 1 << TL_URGENT;
|
|
|
|
|
}
|
2020-01-30 12:37:28 -05:00
|
|
|
|
MEDIUM: tasks: apply a fair CPU distribution between tasklet classes
Till now in process_runnable_tasks() we used to reserve a fixed portion
of max_processed to urgent tasks, then a portion of what remains for
normal tasks, then what remains for bulk tasks. This causes two issues:
- the current budget for processed tasks could be drained once for
all by higher level tasks so that they couldn't have enough left
for the next run. For example, if bulk tasklets cause task wakeups,
the required share to run them could be eaten by other bulk tasklets.
- it forces the urgent tasks to be run before scanning the tree so that
we know how many tasks to pick from the tree, and this isn't very
efficient cache-wise.
This patch changes this so that we compute upfront how max_processed will
be shared between classes that require so. We can then decide in advance
to pick a certain number of tasks from the tree, then execute all tasklets
in turn. When reaching the end, if there's still some budget, we can go
back and do the same thing again, improving chances to pick new work
before the global budget is depleted.
The default weights have been set to 50% for urgent tasklets, 37% for
normal ones and 13% for the bulk ones. In practice, there are not that
many urgent tasklets but when they appear they are cheap and must be
processed in as large batches as possible. Every time there is nothing
to pick there, the unused budget is shared between normal and bulk and
this allows bulk tasklets to still have quite some CPU to run on.
2020-06-24 01:21:08 -04:00
|
|
|
/* execute tasklets in each queue */
|
2020-06-24 04:17:29 -04:00
|
|
|
max_processed -= run_tasks_from_lists(max);
|
2019-04-12 12:03:41 -04:00
|
|
|
|
MEDIUM: tasks: also process late wakeups in process_runnable_tasks()
Since version 1.8, we've started to use tasks and tasklets more
extensively to defer I/O processing. Originally with the simple
scheduler, a task waking another one up using task_wakeup() would
have caused it to be processed right after the list of runnable ones.
With the introduction of tasklets, we've started to spill running
tasks from the run queues to the tasklet queues, so if a task wakes
another one up, it will only be executed on the next call to
process_runnable_task(), which means after yet another round of
polling loop.
This is particularly visible with I/Os hitting muxes: poll() reports
a read event, the connection layer performs a tasklet_wakeup() on the
mux subscribed to this I/O, and this mux in turn signals the upper
layer stream using task_wakeup(). The process goes back to poll() with
a null timeout since there's one active task, then back to checking all
possibly expired events, and finally back to process_runnable_tasks()
again. Worse, when there is high I/O activity, doing so will make the
task's execution further apart from the tasklet and will both increase
the total processing latency and reduce the cache hit ratio.
This patch brings back to the original spirit of process_runnable_tasks()
which is to execute runnable tasks as long as the execution budget is not
exhausted. By doing so, we're immediately cutting in half the number of
calls to all functions called by run_poll_loop(), and halving the number
of calls to poll(). Furthermore, calling poll() less often also means
purging FD updates less often and offering more chances to merge them.
This also has the nice effect of making tune.runqueue-depth effective
again, as in the past it used to be quickly bounded by this artificial
event horizon which was preventing from executing remaining tasks. On
certain workloads we can see a 2-3% performance increase.
2020-06-19 06:17:55 -04:00
|
|
|
/* some tasks may have woken other ones up */
|
2020-06-23 05:32:35 -04:00
|
|
|
if (max_processed > 0 && thread_has_tasks())
|
MEDIUM: tasks: also process late wakeups in process_runnable_tasks()
Since version 1.8, we've started to use tasks and tasklets more
extensively to defer I/O processing. Originally with the simple
scheduler, a task waking another one up using task_wakeup() would
have caused it to be processed right after the list of runnable ones.
With the introduction of tasklets, we've started to spill running
tasks from the run queues to the tasklet queues, so if a task wakes
another one up, it will only be executed on the next call to
process_runnable_task(), which means after yet another round of
polling loop.
This is particularly visible with I/Os hitting muxes: poll() reports
a read event, the connection layer performs a tasklet_wakeup() on the
mux subscribed to this I/O, and this mux in turn signals the upper
layer stream using task_wakeup(). The process goes back to poll() with
a null timeout since there's one active task, then back to checking all
possibly expired events, and finally back to process_runnable_tasks()
again. Worse, when there is high I/O activity, doing so will make the
task's execution further apart from the tasklet and will both increase
the total processing latency and reduce the cache hit ratio.
This patch brings back to the original spirit of process_runnable_tasks()
which is to execute runnable tasks as long as the execution budget is not
exhausted. By doing so, we're immediately cutting in half the number of
calls to all functions called by run_poll_loop(), and halving the number
of calls to poll(). Furthermore, calling poll() less often also means
purging FD updates less often and offering more chances to merge them.
This also has the nice effect of making tune.runqueue-depth effective
again, as in the past it used to be quickly bounded by this artificial
event horizon which was preventing from executing remaining tasks. On
certain workloads we can see a 2-3% performance increase.
2020-06-19 06:17:55 -04:00
|
|
|
goto not_done_yet;
|
|
|
|
|
|
2020-06-24 03:39:48 -04:00
|
|
|
if (tt->tl_class_mask)
|
2019-04-12 12:03:41 -04:00
|
|
|
activity[tid].long_rq++;
|
2006-06-25 20:48:02 -04:00
|
|
|
}
|
|
|
|
|
|
2018-12-06 08:05:20 -05:00
|
|
|
/*
|
|
|
|
|
* Delete every tasks before running the master polling loop
|
|
|
|
|
*/
|
|
|
|
|
void mworker_cleantasks()
|
|
|
|
|
{
|
|
|
|
|
struct task *t;
|
|
|
|
|
int i;
|
2018-12-06 09:14:37 -05:00
|
|
|
struct eb32_node *tmp_wq = NULL;
|
|
|
|
|
struct eb32sc_node *tmp_rq = NULL;
|
2018-12-06 08:05:20 -05:00
|
|
|
|
|
|
|
|
#ifdef USE_THREAD
|
|
|
|
|
/* cleanup the global run queue */
|
2018-12-06 09:14:37 -05:00
|
|
|
tmp_rq = eb32sc_first(&rqueue, MAX_THREADS_MASK);
|
|
|
|
|
while (tmp_rq) {
|
|
|
|
|
t = eb32sc_entry(tmp_rq, struct task, rq);
|
|
|
|
|
tmp_rq = eb32sc_next(tmp_rq, MAX_THREADS_MASK);
|
2019-04-17 16:51:06 -04:00
|
|
|
task_destroy(t);
|
2018-12-06 08:05:20 -05:00
|
|
|
}
|
|
|
|
|
/* cleanup the timers queue */
|
2018-12-06 09:14:37 -05:00
|
|
|
tmp_wq = eb32_first(&timers);
|
|
|
|
|
while (tmp_wq) {
|
|
|
|
|
t = eb32_entry(tmp_wq, struct task, wq);
|
|
|
|
|
tmp_wq = eb32_next(tmp_wq);
|
2019-04-17 16:51:06 -04:00
|
|
|
task_destroy(t);
|
2018-12-06 08:05:20 -05:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
/* clean the per thread run queue */
|
|
|
|
|
for (i = 0; i < global.nbthread; i++) {
|
2021-10-01 05:30:33 -04:00
|
|
|
tmp_rq = eb32sc_first(&ha_thread_ctx[i].rqueue, MAX_THREADS_MASK);
|
2018-12-06 09:14:37 -05:00
|
|
|
while (tmp_rq) {
|
|
|
|
|
t = eb32sc_entry(tmp_rq, struct task, rq);
|
|
|
|
|
tmp_rq = eb32sc_next(tmp_rq, MAX_THREADS_MASK);
|
2019-04-17 16:51:06 -04:00
|
|
|
task_destroy(t);
|
2018-12-06 08:05:20 -05:00
|
|
|
}
|
|
|
|
|
/* cleanup the per thread timers queue */
|
2021-10-01 05:30:33 -04:00
|
|
|
tmp_wq = eb32_first(&ha_thread_ctx[i].timers);
|
2018-12-06 09:14:37 -05:00
|
|
|
while (tmp_wq) {
|
|
|
|
|
t = eb32_entry(tmp_wq, struct task, wq);
|
|
|
|
|
tmp_wq = eb32_next(tmp_wq);
|
2019-04-17 16:51:06 -04:00
|
|
|
task_destroy(t);
|
2018-12-06 08:05:20 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-26 10:31:20 -05:00
|
|
|
/* perform minimal intializations */
|
|
|
|
|
static void init_task()
|
2009-03-07 11:25:21 -05:00
|
|
|
{
|
2021-02-26 03:16:22 -05:00
|
|
|
int i, q;
|
2018-05-18 12:38:23 -04:00
|
|
|
|
2018-06-06 08:22:03 -04:00
|
|
|
#ifdef USE_THREAD
|
2018-10-15 08:52:21 -04:00
|
|
|
memset(&timers, 0, sizeof(timers));
|
2009-03-07 11:25:21 -05:00
|
|
|
memset(&rqueue, 0, sizeof(rqueue));
|
2018-06-06 08:22:03 -04:00
|
|
|
#endif
|
2018-05-18 12:45:28 -04:00
|
|
|
for (i = 0; i < MAX_THREADS; i++) {
|
2021-02-26 03:16:22 -05:00
|
|
|
for (q = 0; q < TL_CLASSES; q++)
|
2021-10-01 05:30:33 -04:00
|
|
|
LIST_INIT(&ha_thread_ctx[i].tasklets[q]);
|
|
|
|
|
MT_LIST_INIT(&ha_thread_ctx[i].shared_tasklet_list);
|
2018-05-18 12:45:28 -04:00
|
|
|
}
|
2009-03-07 11:25:21 -05:00
|
|
|
}
|
|
|
|
|
|
2020-06-24 05:11:02 -04:00
|
|
|
/* config parser for global "tune.sched.low-latency", accepts "on" or "off" */
|
|
|
|
|
static int cfg_parse_tune_sched_low_latency(char **args, int section_type, struct proxy *curpx,
|
2021-03-09 03:53:46 -05:00
|
|
|
const struct proxy *defpx, const char *file, int line,
|
2020-06-24 05:11:02 -04:00
|
|
|
char **err)
|
|
|
|
|
{
|
|
|
|
|
if (too_many_args(1, args, err, NULL))
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
if (strcmp(args[1], "on") == 0)
|
|
|
|
|
global.tune.options |= GTUNE_SCHED_LOW_LATENCY;
|
|
|
|
|
else if (strcmp(args[1], "off") == 0)
|
|
|
|
|
global.tune.options &= ~GTUNE_SCHED_LOW_LATENCY;
|
|
|
|
|
else {
|
|
|
|
|
memprintf(err, "'%s' expects either 'on' or 'off' but got '%s'.", args[0], args[1]);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* config keyword parsers */
|
|
|
|
|
static struct cfg_kw_list cfg_kws = {ILH, {
|
|
|
|
|
{ CFG_GLOBAL, "tune.sched.low-latency", cfg_parse_tune_sched_low_latency },
|
|
|
|
|
{ 0, NULL, NULL }
|
|
|
|
|
}};
|
|
|
|
|
|
|
|
|
|
INITCALL1(STG_REGISTER, cfg_register_keywords, &cfg_kws);
|
2018-11-26 10:31:20 -05:00
|
|
|
INITCALL0(STG_PREPARE, init_task);
|
|
|
|
|
|
2006-06-25 20:48:02 -04:00
|
|
|
/*
|
|
|
|
|
* Local variables:
|
|
|
|
|
* c-indent-level: 8
|
|
|
|
|
* c-basic-offset: 8
|
|
|
|
|
* End:
|
|
|
|
|
*/
|