Commit c8219906 authored Aug 28, 2015 by Eric Dumazet Committed by Linus Torvalds Sep 05, 2015

task_work: remove fifo ordering guarantee



In commit f341861f ("task_work: add a scheduling point in
task_work_run()") I fixed a latency problem adding a cond_resched()
call.

Later, commit ac3d0da8 added yet another loop to reverse a list,
bringing back the latency spike :

I've seen in some cases this loop taking 275 ms, if for example a
process with 2,000,000 files is killed.

We could add yet another cond_resched() in the reverse loop, or we
can simply remove the reversal, as I do not think anything
would depend on order of task_work_add() submitted works.

Fixes: ac3d0da8 ("task_work: Make task_work_add() lockless")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Maciej Żenczykowski <maze@google.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

parent f377ea88

kernel/task_work.c

+2 −10

Original line number	Diff line number	Diff line
		@@ -18,6 +18,8 @@ static struct callback_head work_exited; /* all we need is ->next == NULL */
		* This is like the signal handler which runs in kernel mode, but it doesn't
		* try to wake up the @task.
		*
		* Note: there is no ordering guarantee on works queued here.
		*
		* RETURNS:
		* 0 if succeeds or -ESRCH.
		*/
		@@ -108,16 +110,6 @@ void task_work_run(void)
		raw_spin_unlock_wait(&task->pi_lock);
		smp_mb();

		/* Reverse the list to run the works in fifo order */
		head = NULL;
		do {
		next = work->next;
		work->next = head;
		head = work;
		work = next;
		} while (work);

		work = head;
		do {
		next = work->next;
		work->func(work);

Admin message