2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2002 Sistina Software (UK) Limited.
|
2007-05-09 13:33:02 +04:00
|
|
|
* Copyright (C) 2006 Red Hat GmbH
|
2005-04-17 02:20:36 +04:00
|
|
|
*
|
|
|
|
* This file is released under the GPL.
|
|
|
|
*
|
|
|
|
* Kcopyd provides a simple interface for copying an area of one
|
|
|
|
* block-device to one or more other block-devices, with an asynchronous
|
|
|
|
* completion notification.
|
|
|
|
*/
|
|
|
|
|
2008-04-25 00:43:19 +04:00
|
|
|
#include <linux/types.h>
|
2011-07-27 03:09:06 +04:00
|
|
|
#include <linux/atomic.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/mempool.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/pagemap.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/workqueue.h>
|
2006-03-27 13:18:20 +04:00
|
|
|
#include <linux/mutex.h>
|
2013-03-02 02:45:49 +04:00
|
|
|
#include <linux/delay.h>
|
2008-10-21 20:44:59 +04:00
|
|
|
#include <linux/device-mapper.h>
|
2008-04-25 01:02:01 +04:00
|
|
|
#include <linux/dm-kcopyd.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2016-05-12 23:28:10 +03:00
|
|
|
#include "dm-core.h"
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:00 +04:00
|
|
|
#define SPLIT_COUNT 8
|
|
|
|
#define MIN_JOBS 8
|
2019-07-17 14:24:10 +03:00
|
|
|
|
|
|
|
#define DEFAULT_SUB_JOB_SIZE_KB 512
|
|
|
|
#define MAX_SUB_JOB_SIZE_KB 1024
|
|
|
|
|
|
|
|
static unsigned kcopyd_subjob_size_kb = DEFAULT_SUB_JOB_SIZE_KB;
|
|
|
|
|
|
|
|
module_param(kcopyd_subjob_size_kb, uint, S_IRUGO | S_IWUSR);
|
|
|
|
MODULE_PARM_DESC(kcopyd_subjob_size_kb, "Sub-job size for dm-kcopyd clients");
|
|
|
|
|
|
|
|
static unsigned dm_get_kcopyd_subjob_size(void)
|
|
|
|
{
|
|
|
|
unsigned sub_job_size_kb;
|
|
|
|
|
|
|
|
sub_job_size_kb = __dm_get_module_param(&kcopyd_subjob_size_kb,
|
|
|
|
DEFAULT_SUB_JOB_SIZE_KB,
|
|
|
|
MAX_SUB_JOB_SIZE_KB);
|
|
|
|
|
|
|
|
return sub_job_size_kb << 1;
|
|
|
|
}
|
2011-05-29 16:03:00 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*-----------------------------------------------------------------
|
|
|
|
* Each kcopyd client has its own little pool of preallocated
|
|
|
|
* pages for kcopyd io.
|
|
|
|
*---------------------------------------------------------------*/
|
2008-04-25 00:43:19 +04:00
|
|
|
struct dm_kcopyd_client {
|
2005-04-17 02:20:36 +04:00
|
|
|
struct page_list *pages;
|
2011-05-29 16:03:07 +04:00
|
|
|
unsigned nr_reserved_pages;
|
|
|
|
unsigned nr_free_pages;
|
2019-07-17 14:24:10 +03:00
|
|
|
unsigned sub_job_size;
|
2006-03-27 13:17:50 +04:00
|
|
|
|
2007-05-09 13:33:02 +04:00
|
|
|
struct dm_io_client *io_client;
|
|
|
|
|
2006-03-27 13:17:50 +04:00
|
|
|
wait_queue_head_t destroyq;
|
2008-04-25 00:43:44 +04:00
|
|
|
|
2018-05-21 01:25:53 +03:00
|
|
|
mempool_t job_pool;
|
2008-04-25 00:43:46 +04:00
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
struct workqueue_struct *kcopyd_wq;
|
|
|
|
struct work_struct kcopyd_work;
|
|
|
|
|
2013-03-02 02:45:49 +04:00
|
|
|
struct dm_kcopyd_throttle *throttle;
|
|
|
|
|
2018-05-23 01:26:20 +03:00
|
|
|
atomic_t nr_jobs;
|
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
/*
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
* We maintain four lists of jobs:
|
2008-04-25 00:43:44 +04:00
|
|
|
*
|
|
|
|
* i) jobs waiting for pages
|
|
|
|
* ii) jobs that have pages, and are waiting for the io to be issued.
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
* iii) jobs that don't need to do any IO and just run a callback
|
|
|
|
* iv) jobs that have completed.
|
2008-04-25 00:43:44 +04:00
|
|
|
*
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
* All four of these are protected by job_lock.
|
2008-04-25 00:43:44 +04:00
|
|
|
*/
|
|
|
|
spinlock_t job_lock;
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
struct list_head callback_jobs;
|
2008-04-25 00:43:44 +04:00
|
|
|
struct list_head complete_jobs;
|
|
|
|
struct list_head io_jobs;
|
|
|
|
struct list_head pages_jobs;
|
2005-04-17 02:20:36 +04:00
|
|
|
};
|
|
|
|
|
2011-11-01 00:18:58 +04:00
|
|
|
static struct page_list zero_page_list;
|
|
|
|
|
2013-03-02 02:45:49 +04:00
|
|
|
static DEFINE_SPINLOCK(throttle_spinlock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IO/IDLE accounting slowly decays after (1 << ACCOUNT_INTERVAL_SHIFT) period.
|
|
|
|
* When total_period >= (1 << ACCOUNT_INTERVAL_SHIFT) the counters are divided
|
|
|
|
* by 2.
|
|
|
|
*/
|
|
|
|
#define ACCOUNT_INTERVAL_SHIFT SHIFT_HZ
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sleep this number of milliseconds.
|
|
|
|
*
|
|
|
|
* The value was decided experimentally.
|
|
|
|
* Smaller values seem to cause an increased copy rate above the limit.
|
|
|
|
* The reason for this is unknown but possibly due to jiffies rounding errors
|
|
|
|
* or read/write cache inside the disk.
|
|
|
|
*/
|
|
|
|
#define SLEEP_MSEC 100
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Maximum number of sleep events. There is a theoretical livelock if more
|
|
|
|
* kcopyd clients do work simultaneously which this limit avoids.
|
|
|
|
*/
|
|
|
|
#define MAX_SLEEPS 10
|
|
|
|
|
|
|
|
static void io_job_start(struct dm_kcopyd_throttle *t)
|
|
|
|
{
|
|
|
|
unsigned throttle, now, difference;
|
|
|
|
int slept = 0, skew;
|
|
|
|
|
|
|
|
if (unlikely(!t))
|
|
|
|
return;
|
|
|
|
|
|
|
|
try_again:
|
|
|
|
spin_lock_irq(&throttle_spinlock);
|
|
|
|
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 00:07:29 +03:00
|
|
|
throttle = READ_ONCE(t->throttle);
|
2013-03-02 02:45:49 +04:00
|
|
|
|
|
|
|
if (likely(throttle >= 100))
|
|
|
|
goto skip_limit;
|
|
|
|
|
|
|
|
now = jiffies;
|
|
|
|
difference = now - t->last_jiffies;
|
|
|
|
t->last_jiffies = now;
|
|
|
|
if (t->num_io_jobs)
|
|
|
|
t->io_period += difference;
|
|
|
|
t->total_period += difference;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Maintain sane values if we got a temporary overflow.
|
|
|
|
*/
|
|
|
|
if (unlikely(t->io_period > t->total_period))
|
|
|
|
t->io_period = t->total_period;
|
|
|
|
|
|
|
|
if (unlikely(t->total_period >= (1 << ACCOUNT_INTERVAL_SHIFT))) {
|
|
|
|
int shift = fls(t->total_period >> ACCOUNT_INTERVAL_SHIFT);
|
|
|
|
t->total_period >>= shift;
|
|
|
|
t->io_period >>= shift;
|
|
|
|
}
|
|
|
|
|
|
|
|
skew = t->io_period - throttle * t->total_period / 100;
|
|
|
|
|
|
|
|
if (unlikely(skew > 0) && slept < MAX_SLEEPS) {
|
|
|
|
slept++;
|
|
|
|
spin_unlock_irq(&throttle_spinlock);
|
|
|
|
msleep(SLEEP_MSEC);
|
|
|
|
goto try_again;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_limit:
|
|
|
|
t->num_io_jobs++;
|
|
|
|
|
|
|
|
spin_unlock_irq(&throttle_spinlock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void io_job_finish(struct dm_kcopyd_throttle *t)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
if (unlikely(!t))
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&throttle_spinlock, flags);
|
|
|
|
|
|
|
|
t->num_io_jobs--;
|
|
|
|
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 00:07:29 +03:00
|
|
|
if (likely(READ_ONCE(t->throttle) >= 100))
|
2013-03-02 02:45:49 +04:00
|
|
|
goto skip_limit;
|
|
|
|
|
|
|
|
if (!t->num_io_jobs) {
|
|
|
|
unsigned now, difference;
|
|
|
|
|
|
|
|
now = jiffies;
|
|
|
|
difference = now - t->last_jiffies;
|
|
|
|
t->last_jiffies = now;
|
|
|
|
|
|
|
|
t->io_period += difference;
|
|
|
|
t->total_period += difference;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Maintain sane values if we got a temporary overflow.
|
|
|
|
*/
|
|
|
|
if (unlikely(t->io_period > t->total_period))
|
|
|
|
t->io_period = t->total_period;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_limit:
|
|
|
|
spin_unlock_irqrestore(&throttle_spinlock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
static void wake(struct dm_kcopyd_client *kc)
|
|
|
|
{
|
|
|
|
queue_work(kc->kcopyd_wq, &kc->kcopyd_work);
|
|
|
|
}
|
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
/*
|
|
|
|
* Obtain one page for the use of kcopyd.
|
|
|
|
*/
|
2011-05-29 16:03:04 +04:00
|
|
|
static struct page_list *alloc_pl(gfp_t gfp)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct page_list *pl;
|
|
|
|
|
2011-05-29 16:03:04 +04:00
|
|
|
pl = kmalloc(sizeof(*pl), gfp);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!pl)
|
|
|
|
return NULL;
|
|
|
|
|
2022-07-13 14:05:51 +03:00
|
|
|
pl->page = alloc_page(gfp | __GFP_HIGHMEM);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!pl->page) {
|
|
|
|
kfree(pl);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return pl;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_pl(struct page_list *pl)
|
|
|
|
{
|
|
|
|
__free_page(pl->page);
|
|
|
|
kfree(pl);
|
|
|
|
}
|
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
/*
|
|
|
|
* Add the provided pages to a client's free page list, releasing
|
|
|
|
* back to the system any beyond the reserved_pages limit.
|
|
|
|
*/
|
|
|
|
static void kcopyd_put_pages(struct dm_kcopyd_client *kc, struct page_list *pl)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2011-05-29 16:03:07 +04:00
|
|
|
struct page_list *next;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
do {
|
|
|
|
next = pl->next;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
if (kc->nr_free_pages >= kc->nr_reserved_pages)
|
|
|
|
free_pl(pl);
|
|
|
|
else {
|
|
|
|
pl->next = kc->pages;
|
|
|
|
kc->pages = pl;
|
|
|
|
kc->nr_free_pages++;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
pl = next;
|
|
|
|
} while (pl);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
static int kcopyd_get_pages(struct dm_kcopyd_client *kc,
|
|
|
|
unsigned int nr, struct page_list **pages)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2011-05-29 16:03:07 +04:00
|
|
|
struct page_list *pl;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
*pages = NULL;
|
|
|
|
|
|
|
|
do {
|
2015-11-07 03:28:21 +03:00
|
|
|
pl = alloc_pl(__GFP_NOWARN | __GFP_NORETRY | __GFP_KSWAPD_RECLAIM);
|
2011-05-29 16:03:07 +04:00
|
|
|
if (unlikely(!pl)) {
|
|
|
|
/* Use reserved pages */
|
|
|
|
pl = kc->pages;
|
|
|
|
if (unlikely(!pl))
|
|
|
|
goto out_of_memory;
|
|
|
|
kc->pages = pl->next;
|
|
|
|
kc->nr_free_pages--;
|
|
|
|
}
|
|
|
|
pl->next = *pages;
|
|
|
|
*pages = pl;
|
|
|
|
} while (--nr);
|
|
|
|
|
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
out_of_memory:
|
|
|
|
if (*pages)
|
|
|
|
kcopyd_put_pages(kc, *pages);
|
|
|
|
return -ENOMEM;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These three functions resize the page pool.
|
|
|
|
*/
|
|
|
|
static void drop_pages(struct page_list *pl)
|
|
|
|
{
|
|
|
|
struct page_list *next;
|
|
|
|
|
|
|
|
while (pl) {
|
|
|
|
next = pl->next;
|
|
|
|
free_pl(pl);
|
|
|
|
pl = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
/*
|
|
|
|
* Allocate and reserve nr_pages for the use of a specific client.
|
|
|
|
*/
|
|
|
|
static int client_reserve_pages(struct dm_kcopyd_client *kc, unsigned nr_pages)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2011-05-29 16:03:07 +04:00
|
|
|
unsigned i;
|
2005-04-17 02:20:36 +04:00
|
|
|
struct page_list *pl = NULL, *next;
|
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
for (i = 0; i < nr_pages; i++) {
|
2011-05-29 16:03:04 +04:00
|
|
|
next = alloc_pl(GFP_KERNEL);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!next) {
|
|
|
|
if (pl)
|
|
|
|
drop_pages(pl);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
next->next = pl;
|
|
|
|
pl = next;
|
|
|
|
}
|
|
|
|
|
2011-05-29 16:03:07 +04:00
|
|
|
kc->nr_reserved_pages += nr_pages;
|
2005-04-17 02:20:36 +04:00
|
|
|
kcopyd_put_pages(kc, pl);
|
2011-05-29 16:03:07 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-25 00:43:19 +04:00
|
|
|
static void client_free_pages(struct dm_kcopyd_client *kc)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2011-05-29 16:03:07 +04:00
|
|
|
BUG_ON(kc->nr_free_pages != kc->nr_reserved_pages);
|
2005-04-17 02:20:36 +04:00
|
|
|
drop_pages(kc->pages);
|
|
|
|
kc->pages = NULL;
|
2011-05-29 16:03:07 +04:00
|
|
|
kc->nr_free_pages = kc->nr_reserved_pages = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
|
|
|
* kcopyd_jobs need to be allocated by the *clients* of kcopyd,
|
|
|
|
* for this reason we use a mempool to prevent the client from
|
|
|
|
* ever having to do io (which could cause a deadlock).
|
|
|
|
*---------------------------------------------------------------*/
|
|
|
|
struct kcopyd_job {
|
2008-04-25 00:43:19 +04:00
|
|
|
struct dm_kcopyd_client *kc;
|
2005-04-17 02:20:36 +04:00
|
|
|
struct list_head list;
|
2021-05-26 17:16:01 +03:00
|
|
|
unsigned flags;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Error state of the job.
|
|
|
|
*/
|
|
|
|
int read_err;
|
2008-03-29 00:16:10 +03:00
|
|
|
unsigned long write_err;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
2022-07-14 21:06:48 +03:00
|
|
|
* REQ_OP_READ, REQ_OP_WRITE or REQ_OP_WRITE_ZEROES.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2022-07-14 21:06:48 +03:00
|
|
|
enum req_op op;
|
2008-04-25 00:43:17 +04:00
|
|
|
struct dm_io_region source;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The destinations for the transfer.
|
|
|
|
*/
|
|
|
|
unsigned int num_dests;
|
2008-04-25 00:43:19 +04:00
|
|
|
struct dm_io_region dests[DM_KCOPYD_MAX_REGIONS];
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
struct page_list *pages;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set this to ensure you are notified when the job has
|
|
|
|
* completed. 'context' is for callback to use.
|
|
|
|
*/
|
2008-04-25 00:43:19 +04:00
|
|
|
dm_kcopyd_notify_fn fn;
|
2005-04-17 02:20:36 +04:00
|
|
|
void *context;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These fields are only used if the job has been split
|
|
|
|
* into more manageable parts.
|
|
|
|
*/
|
2007-10-20 01:38:52 +04:00
|
|
|
struct mutex lock;
|
2005-04-17 02:20:36 +04:00
|
|
|
atomic_t sub_jobs;
|
|
|
|
sector_t progress;
|
2017-05-09 02:40:51 +03:00
|
|
|
sector_t write_offset;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:00 +04:00
|
|
|
struct kcopyd_job *master_job;
|
|
|
|
};
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 07:33:20 +03:00
|
|
|
static struct kmem_cache *_job_cache;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-04-25 00:43:49 +04:00
|
|
|
int __init dm_kcopyd_init(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2011-05-29 16:03:00 +04:00
|
|
|
_job_cache = kmem_cache_create("kcopyd_job",
|
|
|
|
sizeof(struct kcopyd_job) * (SPLIT_COUNT + 1),
|
|
|
|
__alignof__(struct kcopyd_job), 0, NULL);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!_job_cache)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2011-11-01 00:18:58 +04:00
|
|
|
zero_page_list.next = &zero_page_list;
|
|
|
|
zero_page_list.page = ZERO_PAGE(0);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-25 00:43:49 +04:00
|
|
|
void dm_kcopyd_exit(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
kmem_cache_destroy(_job_cache);
|
|
|
|
_job_cache = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Functions to push and pop a job onto the head of a given job
|
|
|
|
* list.
|
|
|
|
*/
|
2017-05-09 02:40:51 +03:00
|
|
|
static struct kcopyd_job *pop_io_job(struct list_head *jobs,
|
|
|
|
struct dm_kcopyd_client *kc)
|
|
|
|
{
|
|
|
|
struct kcopyd_job *job;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For I/O jobs, pop any read, any write without sequential write
|
|
|
|
* constraint and sequential writes that are at the right position.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(job, jobs, list) {
|
2022-07-14 21:06:48 +03:00
|
|
|
if (job->op == REQ_OP_READ ||
|
|
|
|
!(job->flags & BIT(DM_KCOPYD_WRITE_SEQ))) {
|
2017-05-09 02:40:51 +03:00
|
|
|
list_del(&job->list);
|
|
|
|
return job;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (job->write_offset == job->master_job->write_offset) {
|
|
|
|
job->master_job->write_offset += job->source.count;
|
|
|
|
list_del(&job->list);
|
|
|
|
return job;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
static struct kcopyd_job *pop(struct list_head *jobs,
|
|
|
|
struct dm_kcopyd_client *kc)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct kcopyd_job *job = NULL;
|
|
|
|
|
2021-05-26 17:18:06 +03:00
|
|
|
spin_lock_irq(&kc->job_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (!list_empty(jobs)) {
|
2017-05-09 02:40:51 +03:00
|
|
|
if (jobs == &kc->io_jobs)
|
|
|
|
job = pop_io_job(jobs, kc);
|
|
|
|
else {
|
|
|
|
job = list_entry(jobs->next, struct kcopyd_job, list);
|
|
|
|
list_del(&job->list);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2021-05-26 17:18:06 +03:00
|
|
|
spin_unlock_irq(&kc->job_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
return job;
|
|
|
|
}
|
|
|
|
|
2007-07-12 20:26:32 +04:00
|
|
|
static void push(struct list_head *jobs, struct kcopyd_job *job)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
2008-04-25 00:43:44 +04:00
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
spin_lock_irqsave(&kc->job_lock, flags);
|
2005-04-17 02:20:36 +04:00
|
|
|
list_add_tail(&job->list, jobs);
|
2008-04-25 00:43:44 +04:00
|
|
|
spin_unlock_irqrestore(&kc->job_lock, flags);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
dm kcopyd: avoid queue shuffle
Write throughput to LVM snapshot origin volume is an order
of magnitude slower than those to LV without snapshots or
snapshot target volumes, especially in the case of sequential
writes with O_SYNC on.
The following patch originally written by Kevin Jamieson and
Jan Blunck and slightly modified for the current RCs by myself
tries to improve the performance by modifying the behaviour
of kcopyd, so that it pushes back an I/O job to the head of
the job queue instead of the tail as process_jobs() currently
does when it has to wait for free pages. This way, write
requests aren't shuffled to cause extra seeks.
I tested the patch against 2.6.27-rc5 and got the following results.
The test is a dd command writing to snapshot origin followed by fsync
to the file just created/updated. A couple of filesystem benchmarks
gave me similar results in case of sequential writes, while random
writes didn't suffer much.
dd if=/dev/zero of=<somewhere on snapshot origin> bs=4096 count=...
[conv=notrunc when updating]
1) linux 2.6.27-rc5 without the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 511.46 610.72 11.81
create,dd+fsync 7.10 6.77 8.13
update,dd 431.63 917.41 12.75
update,dd+fsync 7.79 7.43 8.12
compared with write throughput to LV without any snapshots,
all dd+fsync and 1000 MiB writes perform very poorly.
10M 100M 1000M
create,dd 555.03 608.98 123.29
create,dd+fsync 114.27 72.78 76.65
update,dd 152.34 1267.27 124.04
update,dd+fsync 130.56 77.81 77.84
2) linux 2.6.27-rc5 with the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 537.06 589.44 46.21
create,dd+fsync 31.63 29.19 29.23
update,dd 487.59 897.65 37.76
update,dd+fsync 34.12 30.07 26.85
Although still not on par with plain LV performance -
cannot be avoided because it's copy on write anyway -
this simple patch successfully improves throughtput
of dd+fsync while not affecting the rest.
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Kazuo Ito <ito.kazuo@oss.ntt.co.jp>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Cc: stable@kernel.org
2008-10-21 20:44:50 +04:00
|
|
|
|
|
|
|
static void push_head(struct list_head *jobs, struct kcopyd_job *job)
|
|
|
|
{
|
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
|
|
|
|
2021-05-26 17:18:06 +03:00
|
|
|
spin_lock_irq(&kc->job_lock);
|
dm kcopyd: avoid queue shuffle
Write throughput to LVM snapshot origin volume is an order
of magnitude slower than those to LV without snapshots or
snapshot target volumes, especially in the case of sequential
writes with O_SYNC on.
The following patch originally written by Kevin Jamieson and
Jan Blunck and slightly modified for the current RCs by myself
tries to improve the performance by modifying the behaviour
of kcopyd, so that it pushes back an I/O job to the head of
the job queue instead of the tail as process_jobs() currently
does when it has to wait for free pages. This way, write
requests aren't shuffled to cause extra seeks.
I tested the patch against 2.6.27-rc5 and got the following results.
The test is a dd command writing to snapshot origin followed by fsync
to the file just created/updated. A couple of filesystem benchmarks
gave me similar results in case of sequential writes, while random
writes didn't suffer much.
dd if=/dev/zero of=<somewhere on snapshot origin> bs=4096 count=...
[conv=notrunc when updating]
1) linux 2.6.27-rc5 without the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 511.46 610.72 11.81
create,dd+fsync 7.10 6.77 8.13
update,dd 431.63 917.41 12.75
update,dd+fsync 7.79 7.43 8.12
compared with write throughput to LV without any snapshots,
all dd+fsync and 1000 MiB writes perform very poorly.
10M 100M 1000M
create,dd 555.03 608.98 123.29
create,dd+fsync 114.27 72.78 76.65
update,dd 152.34 1267.27 124.04
update,dd+fsync 130.56 77.81 77.84
2) linux 2.6.27-rc5 with the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 537.06 589.44 46.21
create,dd+fsync 31.63 29.19 29.23
update,dd 487.59 897.65 37.76
update,dd+fsync 34.12 30.07 26.85
Although still not on par with plain LV performance -
cannot be avoided because it's copy on write anyway -
this simple patch successfully improves throughtput
of dd+fsync while not affecting the rest.
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Kazuo Ito <ito.kazuo@oss.ntt.co.jp>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Cc: stable@kernel.org
2008-10-21 20:44:50 +04:00
|
|
|
list_add(&job->list, jobs);
|
2021-05-26 17:18:06 +03:00
|
|
|
spin_unlock_irq(&kc->job_lock);
|
dm kcopyd: avoid queue shuffle
Write throughput to LVM snapshot origin volume is an order
of magnitude slower than those to LV without snapshots or
snapshot target volumes, especially in the case of sequential
writes with O_SYNC on.
The following patch originally written by Kevin Jamieson and
Jan Blunck and slightly modified for the current RCs by myself
tries to improve the performance by modifying the behaviour
of kcopyd, so that it pushes back an I/O job to the head of
the job queue instead of the tail as process_jobs() currently
does when it has to wait for free pages. This way, write
requests aren't shuffled to cause extra seeks.
I tested the patch against 2.6.27-rc5 and got the following results.
The test is a dd command writing to snapshot origin followed by fsync
to the file just created/updated. A couple of filesystem benchmarks
gave me similar results in case of sequential writes, while random
writes didn't suffer much.
dd if=/dev/zero of=<somewhere on snapshot origin> bs=4096 count=...
[conv=notrunc when updating]
1) linux 2.6.27-rc5 without the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 511.46 610.72 11.81
create,dd+fsync 7.10 6.77 8.13
update,dd 431.63 917.41 12.75
update,dd+fsync 7.79 7.43 8.12
compared with write throughput to LV without any snapshots,
all dd+fsync and 1000 MiB writes perform very poorly.
10M 100M 1000M
create,dd 555.03 608.98 123.29
create,dd+fsync 114.27 72.78 76.65
update,dd 152.34 1267.27 124.04
update,dd+fsync 130.56 77.81 77.84
2) linux 2.6.27-rc5 with the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 537.06 589.44 46.21
create,dd+fsync 31.63 29.19 29.23
update,dd 487.59 897.65 37.76
update,dd+fsync 34.12 30.07 26.85
Although still not on par with plain LV performance -
cannot be avoided because it's copy on write anyway -
this simple patch successfully improves throughtput
of dd+fsync while not affecting the rest.
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Kazuo Ito <ito.kazuo@oss.ntt.co.jp>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Cc: stable@kernel.org
2008-10-21 20:44:50 +04:00
|
|
|
}
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* These three functions process 1 item from the corresponding
|
|
|
|
* job list.
|
|
|
|
*
|
|
|
|
* They return:
|
|
|
|
* < 0: error
|
|
|
|
* 0: success
|
|
|
|
* > 0: can't process yet.
|
|
|
|
*/
|
|
|
|
static int run_complete_job(struct kcopyd_job *job)
|
|
|
|
{
|
|
|
|
void *context = job->context;
|
|
|
|
int read_err = job->read_err;
|
2008-03-29 00:16:10 +03:00
|
|
|
unsigned long write_err = job->write_err;
|
2008-04-25 00:43:19 +04:00
|
|
|
dm_kcopyd_notify_fn fn = job->fn;
|
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-11-01 00:18:58 +04:00
|
|
|
if (job->pages && job->pages != &zero_page_list)
|
2009-04-09 03:27:16 +04:00
|
|
|
kcopyd_put_pages(kc, job->pages);
|
2011-05-29 16:03:00 +04:00
|
|
|
/*
|
|
|
|
* If this is the master job, the sub jobs have already
|
|
|
|
* completed so we can free everything.
|
|
|
|
*/
|
2018-01-06 05:17:20 +03:00
|
|
|
if (job->master_job == job) {
|
|
|
|
mutex_destroy(&job->lock);
|
2018-05-21 01:25:53 +03:00
|
|
|
mempool_free(job, &kc->job_pool);
|
2018-01-06 05:17:20 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
fn(read_err, write_err, context);
|
2006-03-27 13:17:50 +04:00
|
|
|
|
|
|
|
if (atomic_dec_and_test(&kc->nr_jobs))
|
|
|
|
wake_up(&kc->destroyq);
|
|
|
|
|
2018-08-06 22:53:12 +03:00
|
|
|
cond_resched();
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void complete_io(unsigned long error, void *context)
|
|
|
|
{
|
|
|
|
struct kcopyd_job *job = (struct kcopyd_job *) context;
|
2008-04-25 00:43:44 +04:00
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-03-02 02:45:49 +04:00
|
|
|
io_job_finish(kc->throttle);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
if (error) {
|
2022-07-14 21:06:48 +03:00
|
|
|
if (op_is_write(job->op))
|
2006-06-26 11:27:30 +04:00
|
|
|
job->write_err |= error;
|
2005-04-17 02:20:36 +04:00
|
|
|
else
|
|
|
|
job->read_err = 1;
|
|
|
|
|
2021-05-26 17:16:01 +03:00
|
|
|
if (!(job->flags & BIT(DM_KCOPYD_IGNORE_ERROR))) {
|
2008-04-25 00:43:44 +04:00
|
|
|
push(&kc->complete_jobs, job);
|
|
|
|
wake(kc);
|
2005-04-17 02:20:36 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-14 21:06:48 +03:00
|
|
|
if (op_is_write(job->op))
|
2008-04-25 00:43:44 +04:00
|
|
|
push(&kc->complete_jobs, job);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
else {
|
2022-07-14 21:06:48 +03:00
|
|
|
job->op = REQ_OP_WRITE;
|
2008-04-25 00:43:44 +04:00
|
|
|
push(&kc->io_jobs, job);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
wake(kc);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Request io on as many buffer heads as we can currently get for
|
|
|
|
* a particular job.
|
|
|
|
*/
|
|
|
|
static int run_io_job(struct kcopyd_job *job)
|
|
|
|
{
|
|
|
|
int r;
|
2007-05-09 13:33:02 +04:00
|
|
|
struct dm_io_request io_req = {
|
2022-07-14 21:06:48 +03:00
|
|
|
.bi_opf = job->op,
|
2007-05-09 13:33:02 +04:00
|
|
|
.mem.type = DM_IO_PAGE_LIST,
|
|
|
|
.mem.ptr.pl = job->pages,
|
2011-08-02 15:32:02 +04:00
|
|
|
.mem.offset = 0,
|
2007-05-09 13:33:02 +04:00
|
|
|
.notify.fn = complete_io,
|
|
|
|
.notify.context = job,
|
|
|
|
.client = job->kc->io_client,
|
|
|
|
};
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2017-05-09 02:40:51 +03:00
|
|
|
/*
|
|
|
|
* If we need to write sequentially and some reads or writes failed,
|
|
|
|
* no point in continuing.
|
|
|
|
*/
|
2021-05-26 17:16:01 +03:00
|
|
|
if (job->flags & BIT(DM_KCOPYD_WRITE_SEQ) &&
|
2019-08-06 02:56:03 +03:00
|
|
|
job->master_job->write_err) {
|
|
|
|
job->write_err = job->master_job->write_err;
|
2017-05-09 02:40:51 +03:00
|
|
|
return -EIO;
|
2019-08-06 02:56:03 +03:00
|
|
|
}
|
2017-05-09 02:40:51 +03:00
|
|
|
|
2013-03-02 02:45:49 +04:00
|
|
|
io_job_start(job->kc->throttle);
|
|
|
|
|
2022-07-14 21:06:48 +03:00
|
|
|
if (job->op == REQ_OP_READ)
|
2007-05-09 13:33:02 +04:00
|
|
|
r = dm_io(&io_req, 1, &job->source, NULL);
|
2011-03-09 13:56:30 +03:00
|
|
|
else
|
2007-05-09 13:33:02 +04:00
|
|
|
r = dm_io(&io_req, job->num_dests, job->dests, NULL);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int run_pages_job(struct kcopyd_job *job)
|
|
|
|
{
|
|
|
|
int r;
|
2011-08-02 15:32:02 +04:00
|
|
|
unsigned nr_pages = dm_div_up(job->dests[0].count, PAGE_SIZE >> 9);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-08-02 15:32:02 +04:00
|
|
|
r = kcopyd_get_pages(job->kc, nr_pages, &job->pages);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!r) {
|
|
|
|
/* this job is ready for io */
|
2008-04-25 00:43:44 +04:00
|
|
|
push(&job->kc->io_jobs, job);
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (r == -ENOMEM)
|
|
|
|
/* can't complete now */
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Run through a list for as long as possible. Returns the count
|
|
|
|
* of successful jobs.
|
|
|
|
*/
|
2008-04-25 00:43:44 +04:00
|
|
|
static int process_jobs(struct list_head *jobs, struct dm_kcopyd_client *kc,
|
|
|
|
int (*fn) (struct kcopyd_job *))
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct kcopyd_job *job;
|
|
|
|
int r, count = 0;
|
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
while ((job = pop(jobs, kc))) {
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
r = fn(job);
|
|
|
|
|
|
|
|
if (r < 0) {
|
|
|
|
/* error this rogue job */
|
2022-07-14 21:06:48 +03:00
|
|
|
if (op_is_write(job->op))
|
2008-03-29 00:16:10 +03:00
|
|
|
job->write_err = (unsigned long) -1L;
|
2005-04-17 02:20:36 +04:00
|
|
|
else
|
|
|
|
job->read_err = 1;
|
2008-04-25 00:43:44 +04:00
|
|
|
push(&kc->complete_jobs, job);
|
2019-08-06 02:56:03 +03:00
|
|
|
wake(kc);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (r > 0) {
|
|
|
|
/*
|
|
|
|
* We couldn't service this job ATM, so
|
|
|
|
* push this job back onto the list.
|
|
|
|
*/
|
dm kcopyd: avoid queue shuffle
Write throughput to LVM snapshot origin volume is an order
of magnitude slower than those to LV without snapshots or
snapshot target volumes, especially in the case of sequential
writes with O_SYNC on.
The following patch originally written by Kevin Jamieson and
Jan Blunck and slightly modified for the current RCs by myself
tries to improve the performance by modifying the behaviour
of kcopyd, so that it pushes back an I/O job to the head of
the job queue instead of the tail as process_jobs() currently
does when it has to wait for free pages. This way, write
requests aren't shuffled to cause extra seeks.
I tested the patch against 2.6.27-rc5 and got the following results.
The test is a dd command writing to snapshot origin followed by fsync
to the file just created/updated. A couple of filesystem benchmarks
gave me similar results in case of sequential writes, while random
writes didn't suffer much.
dd if=/dev/zero of=<somewhere on snapshot origin> bs=4096 count=...
[conv=notrunc when updating]
1) linux 2.6.27-rc5 without the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 511.46 610.72 11.81
create,dd+fsync 7.10 6.77 8.13
update,dd 431.63 917.41 12.75
update,dd+fsync 7.79 7.43 8.12
compared with write throughput to LV without any snapshots,
all dd+fsync and 1000 MiB writes perform very poorly.
10M 100M 1000M
create,dd 555.03 608.98 123.29
create,dd+fsync 114.27 72.78 76.65
update,dd 152.34 1267.27 124.04
update,dd+fsync 130.56 77.81 77.84
2) linux 2.6.27-rc5 with the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 537.06 589.44 46.21
create,dd+fsync 31.63 29.19 29.23
update,dd 487.59 897.65 37.76
update,dd+fsync 34.12 30.07 26.85
Although still not on par with plain LV performance -
cannot be avoided because it's copy on write anyway -
this simple patch successfully improves throughtput
of dd+fsync while not affecting the rest.
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Kazuo Ito <ito.kazuo@oss.ntt.co.jp>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Cc: stable@kernel.org
2008-10-21 20:44:50 +04:00
|
|
|
push_head(jobs, job);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* kcopyd does this every time it's woken up.
|
|
|
|
*/
|
2008-04-25 00:43:44 +04:00
|
|
|
static void do_work(struct work_struct *work)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2008-04-25 00:43:44 +04:00
|
|
|
struct dm_kcopyd_client *kc = container_of(work,
|
|
|
|
struct dm_kcopyd_client, kcopyd_work);
|
2011-03-10 10:52:07 +03:00
|
|
|
struct blk_plug plug;
|
2008-04-25 00:43:44 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* The order that these are called is *very* important.
|
|
|
|
* complete jobs can free some pages for pages jobs.
|
|
|
|
* Pages jobs when successful will jump onto the io jobs
|
|
|
|
* list. io jobs call wake when they complete and it all
|
|
|
|
* starts again.
|
|
|
|
*/
|
2021-05-26 17:18:06 +03:00
|
|
|
spin_lock_irq(&kc->job_lock);
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
list_splice_tail_init(&kc->callback_jobs, &kc->complete_jobs);
|
2021-05-26 17:18:06 +03:00
|
|
|
spin_unlock_irq(&kc->job_lock);
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
|
2011-03-10 10:52:07 +03:00
|
|
|
blk_start_plug(&plug);
|
2008-04-25 00:43:44 +04:00
|
|
|
process_jobs(&kc->complete_jobs, kc, run_complete_job);
|
|
|
|
process_jobs(&kc->pages_jobs, kc, run_pages_job);
|
|
|
|
process_jobs(&kc->io_jobs, kc, run_io_job);
|
2011-03-10 10:52:07 +03:00
|
|
|
blk_finish_plug(&plug);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are copying a small region we just dispatch a single job
|
|
|
|
* to do the copy, otherwise the io has to be split up into many
|
|
|
|
* jobs.
|
|
|
|
*/
|
|
|
|
static void dispatch_job(struct kcopyd_job *job)
|
|
|
|
{
|
2008-04-25 00:43:44 +04:00
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
|
|
|
atomic_inc(&kc->nr_jobs);
|
2009-12-11 02:52:13 +03:00
|
|
|
if (unlikely(!job->source.count))
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
push(&kc->callback_jobs, job);
|
2011-11-01 00:18:58 +04:00
|
|
|
else if (job->pages == &zero_page_list)
|
|
|
|
push(&kc->io_jobs, job);
|
2009-12-11 02:52:13 +03:00
|
|
|
else
|
|
|
|
push(&kc->pages_jobs, job);
|
2008-04-25 00:43:44 +04:00
|
|
|
wake(kc);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2008-03-29 00:16:10 +03:00
|
|
|
static void segment_complete(int read_err, unsigned long write_err,
|
|
|
|
void *context)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
/* FIXME: tidy this function */
|
|
|
|
sector_t progress = 0;
|
|
|
|
sector_t count = 0;
|
2011-05-29 16:03:00 +04:00
|
|
|
struct kcopyd_job *sub_job = (struct kcopyd_job *) context;
|
|
|
|
struct kcopyd_job *job = sub_job->master_job;
|
2009-04-09 03:27:16 +04:00
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2007-10-20 01:38:52 +04:00
|
|
|
mutex_lock(&job->lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/* update the error */
|
|
|
|
if (read_err)
|
|
|
|
job->read_err = 1;
|
|
|
|
|
|
|
|
if (write_err)
|
2006-06-26 11:27:30 +04:00
|
|
|
job->write_err |= write_err;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only dispatch more work if there hasn't been an error.
|
|
|
|
*/
|
|
|
|
if ((!job->read_err && !job->write_err) ||
|
2021-05-26 17:16:01 +03:00
|
|
|
job->flags & BIT(DM_KCOPYD_IGNORE_ERROR)) {
|
2005-04-17 02:20:36 +04:00
|
|
|
/* get the next chunk of work */
|
|
|
|
progress = job->progress;
|
|
|
|
count = job->source.count - progress;
|
|
|
|
if (count) {
|
2019-07-17 14:24:10 +03:00
|
|
|
if (count > kc->sub_job_size)
|
|
|
|
count = kc->sub_job_size;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
job->progress += count;
|
|
|
|
}
|
|
|
|
}
|
2007-10-20 01:38:52 +04:00
|
|
|
mutex_unlock(&job->lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (count) {
|
|
|
|
int i;
|
|
|
|
|
|
|
|
*sub_job = *job;
|
2017-05-09 02:40:51 +03:00
|
|
|
sub_job->write_offset = progress;
|
2005-04-17 02:20:36 +04:00
|
|
|
sub_job->source.sector += progress;
|
|
|
|
sub_job->source.count = count;
|
|
|
|
|
|
|
|
for (i = 0; i < job->num_dests; i++) {
|
|
|
|
sub_job->dests[i].sector += progress;
|
|
|
|
sub_job->dests[i].count = count;
|
|
|
|
}
|
|
|
|
|
|
|
|
sub_job->fn = segment_complete;
|
2011-05-29 16:03:00 +04:00
|
|
|
sub_job->context = sub_job;
|
2005-04-17 02:20:36 +04:00
|
|
|
dispatch_job(sub_job);
|
|
|
|
|
|
|
|
} else if (atomic_dec_and_test(&job->sub_jobs)) {
|
|
|
|
|
|
|
|
/*
|
2009-04-09 03:27:17 +04:00
|
|
|
* Queue the completion callback to the kcopyd thread.
|
|
|
|
*
|
|
|
|
* Some callers assume that all the completions are called
|
|
|
|
* from a single thread and don't race with each other.
|
|
|
|
*
|
|
|
|
* We must not call the callback directly here because this
|
|
|
|
* code may not be executing in the thread.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2009-04-09 03:27:17 +04:00
|
|
|
push(&kc->complete_jobs, job);
|
|
|
|
wake(kc);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-05-29 16:03:00 +04:00
|
|
|
* Create some sub jobs to share the work between them.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2011-05-29 16:03:00 +04:00
|
|
|
static void split_job(struct kcopyd_job *master_job)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2011-05-29 16:03:00 +04:00
|
|
|
atomic_inc(&master_job->kc->nr_jobs);
|
2009-04-09 03:27:17 +04:00
|
|
|
|
2011-05-29 16:03:00 +04:00
|
|
|
atomic_set(&master_job->sub_jobs, SPLIT_COUNT);
|
|
|
|
for (i = 0; i < SPLIT_COUNT; i++) {
|
|
|
|
master_job[i + 1].master_job = master_job;
|
|
|
|
segment_complete(0, 0u, &master_job[i + 1]);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2018-08-01 00:27:02 +03:00
|
|
|
void dm_kcopyd_copy(struct dm_kcopyd_client *kc, struct dm_io_region *from,
|
|
|
|
unsigned int num_dests, struct dm_io_region *dests,
|
|
|
|
unsigned int flags, dm_kcopyd_notify_fn fn, void *context)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct kcopyd_job *job;
|
2012-12-22 00:23:37 +04:00
|
|
|
int i;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
2011-05-29 16:03:00 +04:00
|
|
|
* Allocate an array of jobs consisting of one master job
|
|
|
|
* followed by SPLIT_COUNT sub jobs.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2018-05-21 01:25:53 +03:00
|
|
|
job = mempool_alloc(&kc->job_pool, GFP_NOIO);
|
2018-01-06 05:17:20 +03:00
|
|
|
mutex_init(&job->lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* set up for the read.
|
|
|
|
*/
|
|
|
|
job->kc = kc;
|
|
|
|
job->flags = flags;
|
|
|
|
job->read_err = 0;
|
|
|
|
job->write_err = 0;
|
|
|
|
|
|
|
|
job->num_dests = num_dests;
|
|
|
|
memcpy(&job->dests, dests, sizeof(*dests) * num_dests);
|
|
|
|
|
2017-05-09 02:40:51 +03:00
|
|
|
/*
|
|
|
|
* If one of the destination is a host-managed zoned block device,
|
|
|
|
* we need to write sequentially. If one of the destination is a
|
|
|
|
* host-aware device, then leave it to the caller to choose what to do.
|
|
|
|
*/
|
2021-05-26 17:16:01 +03:00
|
|
|
if (!(job->flags & BIT(DM_KCOPYD_WRITE_SEQ))) {
|
2017-05-09 02:40:51 +03:00
|
|
|
for (i = 0; i < job->num_dests; i++) {
|
|
|
|
if (bdev_zoned_model(dests[i].bdev) == BLK_ZONED_HM) {
|
2021-05-26 17:16:01 +03:00
|
|
|
job->flags |= BIT(DM_KCOPYD_WRITE_SEQ);
|
2017-05-09 02:40:51 +03:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we need to write sequentially, errors cannot be ignored.
|
|
|
|
*/
|
2021-05-26 17:16:01 +03:00
|
|
|
if (job->flags & BIT(DM_KCOPYD_WRITE_SEQ) &&
|
|
|
|
job->flags & BIT(DM_KCOPYD_IGNORE_ERROR))
|
|
|
|
job->flags &= ~BIT(DM_KCOPYD_IGNORE_ERROR);
|
2017-05-09 02:40:51 +03:00
|
|
|
|
2011-11-01 00:18:58 +04:00
|
|
|
if (from) {
|
|
|
|
job->source = *from;
|
|
|
|
job->pages = NULL;
|
2022-07-14 21:06:48 +03:00
|
|
|
job->op = REQ_OP_READ;
|
2011-11-01 00:18:58 +04:00
|
|
|
} else {
|
|
|
|
memset(&job->source, 0, sizeof job->source);
|
|
|
|
job->source.count = job->dests[0].count;
|
|
|
|
job->pages = &zero_page_list;
|
2012-12-22 00:23:37 +04:00
|
|
|
|
|
|
|
/*
|
2017-04-05 20:21:06 +03:00
|
|
|
* Use WRITE ZEROES to optimize zeroing if all dests support it.
|
2012-12-22 00:23:37 +04:00
|
|
|
*/
|
2022-07-14 21:06:48 +03:00
|
|
|
job->op = REQ_OP_WRITE_ZEROES;
|
2012-12-22 00:23:37 +04:00
|
|
|
for (i = 0; i < job->num_dests; i++)
|
2017-04-05 20:21:06 +03:00
|
|
|
if (!bdev_write_zeroes_sectors(job->dests[i].bdev)) {
|
2022-07-14 21:06:48 +03:00
|
|
|
job->op = REQ_OP_WRITE;
|
2012-12-22 00:23:37 +04:00
|
|
|
break;
|
|
|
|
}
|
2011-11-01 00:18:58 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
job->fn = fn;
|
|
|
|
job->context = context;
|
2011-05-29 16:03:00 +04:00
|
|
|
job->master_job = job;
|
2017-05-09 02:40:51 +03:00
|
|
|
job->write_offset = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2019-07-17 14:24:10 +03:00
|
|
|
if (job->source.count <= kc->sub_job_size)
|
2005-04-17 02:20:36 +04:00
|
|
|
dispatch_job(job);
|
|
|
|
else {
|
|
|
|
job->progress = 0;
|
|
|
|
split_job(job);
|
|
|
|
}
|
|
|
|
}
|
2008-04-25 00:43:19 +04:00
|
|
|
EXPORT_SYMBOL(dm_kcopyd_copy);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2018-08-01 00:27:02 +03:00
|
|
|
void dm_kcopyd_zero(struct dm_kcopyd_client *kc,
|
|
|
|
unsigned num_dests, struct dm_io_region *dests,
|
|
|
|
unsigned flags, dm_kcopyd_notify_fn fn, void *context)
|
2011-11-01 00:18:58 +04:00
|
|
|
{
|
2018-08-01 00:27:02 +03:00
|
|
|
dm_kcopyd_copy(kc, NULL, num_dests, dests, flags, fn, context);
|
2011-11-01 00:18:58 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_kcopyd_zero);
|
|
|
|
|
2011-08-02 15:32:04 +04:00
|
|
|
void *dm_kcopyd_prepare_callback(struct dm_kcopyd_client *kc,
|
|
|
|
dm_kcopyd_notify_fn fn, void *context)
|
|
|
|
{
|
|
|
|
struct kcopyd_job *job;
|
|
|
|
|
2018-05-21 01:25:53 +03:00
|
|
|
job = mempool_alloc(&kc->job_pool, GFP_NOIO);
|
2011-08-02 15:32:04 +04:00
|
|
|
|
|
|
|
memset(job, 0, sizeof(struct kcopyd_job));
|
|
|
|
job->kc = kc;
|
|
|
|
job->fn = fn;
|
|
|
|
job->context = context;
|
2011-10-23 23:55:17 +04:00
|
|
|
job->master_job = job;
|
2011-08-02 15:32:04 +04:00
|
|
|
|
|
|
|
atomic_inc(&kc->nr_jobs);
|
|
|
|
|
|
|
|
return job;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_kcopyd_prepare_callback);
|
|
|
|
|
|
|
|
void dm_kcopyd_do_callback(void *j, int read_err, unsigned long write_err)
|
|
|
|
{
|
|
|
|
struct kcopyd_job *job = j;
|
|
|
|
struct dm_kcopyd_client *kc = job->kc;
|
|
|
|
|
|
|
|
job->read_err = read_err;
|
|
|
|
job->write_err = write_err;
|
|
|
|
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
push(&kc->callback_jobs, job);
|
2011-08-02 15:32:04 +04:00
|
|
|
wake(kc);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_kcopyd_do_callback);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* Cancels a kcopyd job, eg. someone might be deactivating a
|
|
|
|
* mirror.
|
|
|
|
*/
|
2006-01-06 11:20:08 +03:00
|
|
|
#if 0
|
2005-04-17 02:20:36 +04:00
|
|
|
int kcopyd_cancel(struct kcopyd_job *job, int block)
|
|
|
|
{
|
|
|
|
/* FIXME: finish */
|
|
|
|
return -1;
|
|
|
|
}
|
2006-01-06 11:20:08 +03:00
|
|
|
#endif /* 0 */
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
2008-04-25 00:43:49 +04:00
|
|
|
* Client setup
|
2005-04-17 02:20:36 +04:00
|
|
|
*---------------------------------------------------------------*/
|
2013-03-02 02:45:49 +04:00
|
|
|
struct dm_kcopyd_client *dm_kcopyd_client_create(struct dm_kcopyd_throttle *throttle)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2018-05-21 01:25:53 +03:00
|
|
|
int r;
|
2019-07-17 14:24:10 +03:00
|
|
|
unsigned reserve_pages;
|
2008-04-25 00:43:19 +04:00
|
|
|
struct dm_kcopyd_client *kc;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2018-06-05 12:26:33 +03:00
|
|
|
kc = kzalloc(sizeof(*kc), GFP_KERNEL);
|
2008-04-25 00:43:49 +04:00
|
|
|
if (!kc)
|
2011-05-29 16:03:13 +04:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
spin_lock_init(&kc->job_lock);
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
INIT_LIST_HEAD(&kc->callback_jobs);
|
2008-04-25 00:43:44 +04:00
|
|
|
INIT_LIST_HEAD(&kc->complete_jobs);
|
|
|
|
INIT_LIST_HEAD(&kc->io_jobs);
|
|
|
|
INIT_LIST_HEAD(&kc->pages_jobs);
|
2013-03-02 02:45:49 +04:00
|
|
|
kc->throttle = throttle;
|
2008-04-25 00:43:44 +04:00
|
|
|
|
2018-05-21 01:25:53 +03:00
|
|
|
r = mempool_init_slab_pool(&kc->job_pool, MIN_JOBS, _job_cache);
|
|
|
|
if (r)
|
2008-04-25 00:43:49 +04:00
|
|
|
goto bad_slab;
|
2008-04-25 00:43:46 +04:00
|
|
|
|
2008-04-25 00:43:44 +04:00
|
|
|
INIT_WORK(&kc->kcopyd_work, do_work);
|
2013-07-30 16:40:21 +04:00
|
|
|
kc->kcopyd_wq = alloc_workqueue("kcopyd", WQ_MEM_RECLAIM, 0);
|
2018-05-21 01:25:53 +03:00
|
|
|
if (!kc->kcopyd_wq) {
|
|
|
|
r = -ENOMEM;
|
2008-04-25 00:43:49 +04:00
|
|
|
goto bad_workqueue;
|
2018-05-21 01:25:53 +03:00
|
|
|
}
|
2008-04-25 00:43:44 +04:00
|
|
|
|
2019-07-17 14:24:10 +03:00
|
|
|
kc->sub_job_size = dm_get_kcopyd_subjob_size();
|
|
|
|
reserve_pages = DIV_ROUND_UP(kc->sub_job_size << SECTOR_SHIFT, PAGE_SIZE);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
kc->pages = NULL;
|
2011-05-29 16:03:07 +04:00
|
|
|
kc->nr_reserved_pages = kc->nr_free_pages = 0;
|
2019-07-17 14:24:10 +03:00
|
|
|
r = client_reserve_pages(kc, reserve_pages);
|
2008-04-25 00:43:49 +04:00
|
|
|
if (r)
|
|
|
|
goto bad_client_pages;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-05-29 16:03:09 +04:00
|
|
|
kc->io_client = dm_io_client_create();
|
2007-05-09 13:33:02 +04:00
|
|
|
if (IS_ERR(kc->io_client)) {
|
|
|
|
r = PTR_ERR(kc->io_client);
|
2008-04-25 00:43:49 +04:00
|
|
|
goto bad_io_client;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2006-03-27 13:17:50 +04:00
|
|
|
init_waitqueue_head(&kc->destroyq);
|
|
|
|
atomic_set(&kc->nr_jobs, 0);
|
|
|
|
|
2011-05-29 16:03:13 +04:00
|
|
|
return kc;
|
2008-04-25 00:43:49 +04:00
|
|
|
|
|
|
|
bad_io_client:
|
|
|
|
client_free_pages(kc);
|
|
|
|
bad_client_pages:
|
|
|
|
destroy_workqueue(kc->kcopyd_wq);
|
|
|
|
bad_workqueue:
|
2018-05-21 01:25:53 +03:00
|
|
|
mempool_exit(&kc->job_pool);
|
2008-04-25 00:43:49 +04:00
|
|
|
bad_slab:
|
|
|
|
kfree(kc);
|
|
|
|
|
2011-05-29 16:03:13 +04:00
|
|
|
return ERR_PTR(r);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2008-04-25 00:43:19 +04:00
|
|
|
EXPORT_SYMBOL(dm_kcopyd_client_create);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-04-25 00:43:19 +04:00
|
|
|
void dm_kcopyd_client_destroy(struct dm_kcopyd_client *kc)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2006-03-27 13:17:50 +04:00
|
|
|
/* Wait for completion of all jobs submitted by this client. */
|
|
|
|
wait_event(kc->destroyq, !atomic_read(&kc->nr_jobs));
|
|
|
|
|
dm kcopyd: Fix bug causing workqueue stalls
When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
submitting copy jobs with a source size of 0, the jobs are pushed
directly to the complete_jobs list, which could be under processing by
the kcopyd thread. As a result, the kcopyd thread can continue running
completed jobs indefinitely, without releasing the CPU, as long as
someone keeps submitting new completed jobs through the aforementioned
paths. Processing of work items, queued for execution on the same CPU as
the currently running kcopyd thread, is thus stalled for excessive
amounts of time, hurting performance.
Running the following test, from the device mapper test suite [1],
dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
, with 8 active snapshots, we get, in dmesg, messages like the
following:
[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
[68899.949282] Showing busy workqueues and worker pools:
[68899.949288] workqueue events: flags=0x0
[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949306] pending: vmstat_shepherd, cache_reap
[68899.949331] workqueue mm_percpu_wq: flags=0x8
[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949345] pending: vmstat_update
[68899.949387] workqueue dm_bufio_cache: flags=0x8
[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
[68899.949400] pending: work_fn [dm_bufio]
[68899.949423] workqueue kcopyd: flags=0x8
[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949437] pending: do_work [dm_mod]
[68899.949452] workqueue kcopyd: flags=0x8
[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
[68899.949466] in-flight: 13:do_work [dm_mod]
[68899.949474] pending: do_work [dm_mod]
[68899.949487] workqueue kcopyd: flags=0x8
[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949501] pending: do_work [dm_mod]
[68899.949515] workqueue kcopyd: flags=0x8
[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949529] pending: do_work [dm_mod]
[68899.949541] workqueue kcopyd: flags=0x8
[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
[68899.949555] pending: do_work [dm_mod]
[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
Fix this by splitting the complete_jobs list into two parts: A user
facing part, named callback_jobs, and one used internally by kcopyd,
retaining the name complete_jobs. dm_kcopyd_do_callback() and
dispatch_job() now push their jobs to the callback_jobs list, which is
spliced to the complete_jobs list once, every time the kcopyd thread
wakes up. This prevents kcopyd from hogging the CPU indefinitely and
causing workqueue stalls.
Re-running the aforementioned test:
* Workqueue stalls are eliminated
* The maximum writing time among all targets is reduced from 09m37.10s
to 06m04.85s and the total run time of the test is reduced from
10m43.591s to 7m19.199s
[1] https://github.com/jthornber/device-mapper-test-suite
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-11-01 00:53:09 +03:00
|
|
|
BUG_ON(!list_empty(&kc->callback_jobs));
|
2008-04-25 00:43:44 +04:00
|
|
|
BUG_ON(!list_empty(&kc->complete_jobs));
|
|
|
|
BUG_ON(!list_empty(&kc->io_jobs));
|
|
|
|
BUG_ON(!list_empty(&kc->pages_jobs));
|
|
|
|
destroy_workqueue(kc->kcopyd_wq);
|
2007-05-09 13:33:02 +04:00
|
|
|
dm_io_client_destroy(kc->io_client);
|
2005-04-17 02:20:36 +04:00
|
|
|
client_free_pages(kc);
|
2018-05-21 01:25:53 +03:00
|
|
|
mempool_exit(&kc->job_pool);
|
2005-04-17 02:20:36 +04:00
|
|
|
kfree(kc);
|
|
|
|
}
|
2008-04-25 00:43:19 +04:00
|
|
|
EXPORT_SYMBOL(dm_kcopyd_client_destroy);
|
2021-06-15 21:17:35 +03:00
|
|
|
|
|
|
|
void dm_kcopyd_client_flush(struct dm_kcopyd_client *kc)
|
|
|
|
{
|
|
|
|
flush_workqueue(kc->kcopyd_wq);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_kcopyd_client_flush);
|