padata: Replace delayed timer with immediate workqueue in padata_reorder
authorHerbert Xu <herbert@gondor.apana.org.au>
Thu, 18 Jul 2019 15:01:46 +0000 (23:01 +0800)
committerBen Hutchings <ben@decadent.org.uk>
Fri, 22 May 2020 20:19:13 +0000 (21:19 +0100)
commitf4403b5f4c42f2306a087b7f57f6205bac6a34ed
treebb4681fa66088f9d5faf1f9d79558a3b220472a1
parentbe34320e2646096f6aca13ad607731499a9fc1b2
padata: Replace delayed timer with immediate workqueue in padata_reorder

commit 6fc4dbcf0276279d488c5fbbfabe94734134f4fa upstream.

The function padata_reorder will use a timer when it cannot progress
while completed jobs are outstanding (pd->reorder_objects > 0).  This
is suboptimal as if we do end up using the timer then it would have
introduced a gratuitous delay of one second.

In fact we can easily distinguish between whether completed jobs
are outstanding and whether we can make progress.  All we have to
do is look at the next pqueue list.

This patch does that by replacing pd->processed with pd->cpu so
that the next pqueue is more accessible.

A work queue is used instead of the original try_again to avoid
hogging the CPU.

Note that we don't bother removing the work queue in
padata_flush_queues because the whole premise is broken.  You
cannot flush async crypto requests so it makes no sense to even
try.  A subsequent patch will fix it by replacing it with a ref
counting scheme.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[bwh: Backported to 3.16: Deleted code used the old timer API here]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
include/linux/padata.h
kernel/padata.c