License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2010-09-16 05:06:35 +08:00
|
|
|
/*
|
|
|
|
* Interface for controlling IO bandwidth on a request queue
|
|
|
|
*
|
|
|
|
* Copyright (C) 2010 Vivek Goyal <vgoyal@redhat.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/bio.h>
|
|
|
|
#include <linux/blktrace_api.h>
|
2011-10-19 20:31:18 +08:00
|
|
|
#include "blk.h"
|
2019-11-08 03:18:04 +08:00
|
|
|
#include "blk-cgroup-rwstat.h"
|
2021-11-24 02:53:09 +08:00
|
|
|
#include "blk-stat.h"
|
2021-10-05 23:11:56 +08:00
|
|
|
#include "blk-throttle.h"
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
/* Max dispatch from a group in 1 round */
|
2020-09-07 16:10:15 +08:00
|
|
|
#define THROTL_GRP_QUANTUM 8
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
/* Total max dispatch from all groups in one round */
|
2020-09-07 16:10:15 +08:00
|
|
|
#define THROTL_QUANTUM 32
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2017-03-28 01:51:38 +08:00
|
|
|
/* Throttling is performed over a slice and after that slice is renewed */
|
|
|
|
#define DFL_THROTL_SLICE_HD (HZ / 10)
|
|
|
|
#define DFL_THROTL_SLICE_SSD (HZ / 50)
|
2017-03-28 01:51:37 +08:00
|
|
|
#define MAX_THROTL_SLICE (HZ)
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
#define MAX_IDLE_TIME (5L * 1000 * 1000) /* 5 s */
|
2017-05-18 04:07:26 +08:00
|
|
|
#define MIN_THROTL_BPS (320 * 1024)
|
|
|
|
#define MIN_THROTL_IOPS (10)
|
2017-05-18 04:07:27 +08:00
|
|
|
#define DFL_LATENCY_TARGET (-1L)
|
|
|
|
#define DFL_IDLE_THRESHOLD (0)
|
2017-06-07 03:40:43 +08:00
|
|
|
#define DFL_HD_BASELINE_LATENCY (4000L) /* 4ms */
|
|
|
|
#define LATENCY_FILTERED_SSD (0)
|
|
|
|
/*
|
|
|
|
* For HD, very small latency comes from sequential IO. Such IO is helpless to
|
|
|
|
* help determine if its IO is impacted by others, hence we ignore the IO
|
|
|
|
*/
|
|
|
|
#define LATENCY_FILTERED_HD (1000L) /* 1ms */
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2011-03-02 02:40:54 +08:00
|
|
|
/* A workqueue to queue throttle related work */
|
|
|
|
static struct workqueue_struct *kthrotld_workqueue;
|
|
|
|
|
2010-09-16 05:06:35 +08:00
|
|
|
#define rb_entry_tg(node) rb_entry((node), struct throtl_grp, rb_node)
|
|
|
|
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
/* We measure latency for request size from <= 4k to >= 1M */
|
|
|
|
#define LATENCY_BUCKET_SIZE 9
|
|
|
|
|
|
|
|
struct latency_bucket {
|
|
|
|
unsigned long total_latency; /* ns / 1024 */
|
|
|
|
int samples;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct avg_latency_bucket {
|
|
|
|
unsigned long latency; /* ns / 1024 */
|
|
|
|
bool valid;
|
|
|
|
};
|
|
|
|
|
2010-09-16 05:06:35 +08:00
|
|
|
struct throtl_data
|
|
|
|
{
|
|
|
|
/* service tree for active throtl groups */
|
2013-05-15 04:52:32 +08:00
|
|
|
struct throtl_service_queue service_queue;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
struct request_queue *queue;
|
|
|
|
|
|
|
|
/* Total Number of queued bios on READ and WRITE lists */
|
|
|
|
unsigned int nr_queued[2];
|
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
unsigned int throtl_slice;
|
|
|
|
|
2010-09-16 05:06:35 +08:00
|
|
|
/* Work for dispatching throttled bios */
|
2013-05-15 04:52:36 +08:00
|
|
|
struct work_struct dispatch_work;
|
2017-03-28 01:51:30 +08:00
|
|
|
unsigned int limit_index;
|
|
|
|
bool limit_valid[LIMIT_CNT];
|
2017-03-28 01:51:35 +08:00
|
|
|
|
|
|
|
unsigned long low_upgrade_time;
|
|
|
|
unsigned long low_downgrade_time;
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
|
|
|
|
unsigned int scale;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
struct latency_bucket tmp_buckets[2][LATENCY_BUCKET_SIZE];
|
|
|
|
struct avg_latency_bucket avg_buckets[2][LATENCY_BUCKET_SIZE];
|
|
|
|
struct latency_bucket __percpu *latency_buckets[2];
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
unsigned long last_calculate_time;
|
2017-06-07 03:40:43 +08:00
|
|
|
unsigned long filtered_latency;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
|
|
|
bool track_bio_latency;
|
2010-09-16 05:06:35 +08:00
|
|
|
};
|
|
|
|
|
treewide: setup_timer() -> timer_setup()
This converts all remaining cases of the old setup_timer() API into using
timer_setup(), where the callback argument is the structure already
holding the struct timer_list. These should have no behavioral changes,
since they just change which pointer is passed into the callback with
the same available pointers after conversion. It handles the following
examples, in addition to some other variations.
Casting from unsigned long:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
setup_timer(&ptr->my_timer, my_callback, ptr);
and forced object casts:
void my_callback(struct something *ptr)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, (unsigned long)ptr);
become:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
Direct function assignments:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
ptr->my_timer.function = my_callback;
have a temporary cast added, along with converting the args:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
ptr->my_timer.function = (TIMER_FUNC_TYPE)my_callback;
And finally, callbacks without a data assignment:
void my_callback(unsigned long data)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, 0);
have their argument renamed to verify they're unused during conversion:
void my_callback(struct timer_list *unused)
{
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
The conversion is done with the following Coccinelle script:
spatch --very-quiet --all-includes --include-headers \
-I ./arch/x86/include -I ./arch/x86/include/generated \
-I ./include -I ./arch/x86/include/uapi \
-I ./arch/x86/include/generated/uapi -I ./include/uapi \
-I ./include/generated/uapi --include ./include/linux/kconfig.h \
--dir . \
--cocci-file ~/src/data/timer_setup.cocci
@fix_address_of@
expression e;
@@
setup_timer(
-&(e)
+&e
, ...)
// Update any raw setup_timer() usages that have a NULL callback, but
// would otherwise match change_timer_function_usage, since the latter
// will update all function assignments done in the face of a NULL
// function initialization in setup_timer().
@change_timer_function_usage_NULL@
expression _E;
identifier _timer;
type _cast_data;
@@
(
-setup_timer(&_E->_timer, NULL, _E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E->_timer, NULL, (_cast_data)_E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, &_E);
+timer_setup(&_E._timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, (_cast_data)&_E);
+timer_setup(&_E._timer, NULL, 0);
)
@change_timer_function_usage@
expression _E;
identifier _timer;
struct timer_list _stl;
identifier _callback;
type _cast_func, _cast_data;
@@
(
-setup_timer(&_E->_timer, _callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
_E->_timer@_stl.function = _callback;
|
_E->_timer@_stl.function = &_callback;
|
_E->_timer@_stl.function = (_cast_func)_callback;
|
_E->_timer@_stl.function = (_cast_func)&_callback;
|
_E._timer@_stl.function = _callback;
|
_E._timer@_stl.function = &_callback;
|
_E._timer@_stl.function = (_cast_func)_callback;
|
_E._timer@_stl.function = (_cast_func)&_callback;
)
// callback(unsigned long arg)
@change_callback_handle_cast
depends on change_timer_function_usage@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
identifier _handle;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
(
... when != _origarg
_handletype *_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
)
}
// callback(unsigned long arg) without existing variable
@change_callback_handle_cast_no_arg
depends on change_timer_function_usage &&
!change_callback_handle_cast@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
+ _handletype *_origarg = from_timer(_origarg, t, _timer);
+
... when != _origarg
- (_handletype *)_origarg
+ _origarg
... when != _origarg
}
// Avoid already converted callbacks.
@match_callback_converted
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier t;
@@
void _callback(struct timer_list *t)
{ ... }
// callback(struct something *handle)
@change_callback_handle_arg
depends on change_timer_function_usage &&
!match_callback_converted &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
@@
void _callback(
-_handletype *_handle
+struct timer_list *t
)
{
+ _handletype *_handle = from_timer(_handle, t, _timer);
...
}
// If change_callback_handle_arg ran on an empty function, remove
// the added handler.
@unchange_callback_handle_arg
depends on change_timer_function_usage &&
change_callback_handle_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
identifier t;
@@
void _callback(struct timer_list *t)
{
- _handletype *_handle = from_timer(_handle, t, _timer);
}
// We only want to refactor the setup_timer() data argument if we've found
// the matching callback. This undoes changes in change_timer_function_usage.
@unchange_timer_function_usage
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg &&
!change_callback_handle_arg@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type change_timer_function_usage._cast_data;
@@
(
-timer_setup(&_E->_timer, _callback, 0);
+setup_timer(&_E->_timer, _callback, (_cast_data)_E);
|
-timer_setup(&_E._timer, _callback, 0);
+setup_timer(&_E._timer, _callback, (_cast_data)&_E);
)
// If we fixed a callback from a .function assignment, fix the
// assignment cast now.
@change_timer_function_assignment
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_func;
typedef TIMER_FUNC_TYPE;
@@
(
_E->_timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-&_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
)
// Sometimes timer functions are called directly. Replace matched args.
@change_timer_function_calls
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression _E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_data;
@@
_callback(
(
-(_cast_data)_E
+&_E->_timer
|
-(_cast_data)&_E
+&_E._timer
|
-_E
+&_E->_timer
)
)
// If a timer has been configured without a data argument, it can be
// converted without regard to the callback argument, since it is unused.
@match_timer_function_unused_data@
expression _E;
identifier _timer;
identifier _callback;
@@
(
-setup_timer(&_E->_timer, _callback, 0);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0L);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0UL);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0L);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0UL);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0L);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0UL);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0L);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0UL);
+timer_setup(_timer, _callback, 0);
)
@change_callback_unused_data
depends on match_timer_function_unused_data@
identifier match_timer_function_unused_data._callback;
type _origtype;
identifier _origarg;
@@
void _callback(
-_origtype _origarg
+struct timer_list *unused
)
{
... when != _origarg
}
Signed-off-by: Kees Cook <keescook@chromium.org>
2017-10-17 05:43:17 +08:00
|
|
|
static void throtl_pending_timer_fn(struct timer_list *t);
|
2013-05-15 04:52:36 +08:00
|
|
|
|
2012-04-17 04:57:25 +08:00
|
|
|
static inline struct blkcg_gq *tg_to_blkg(struct throtl_grp *tg)
|
2012-03-06 05:15:14 +08:00
|
|
|
{
|
2012-04-17 04:57:26 +08:00
|
|
|
return pd_to_blkg(&tg->pd);
|
2012-03-06 05:15:14 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
/**
|
|
|
|
* sq_to_tg - return the throl_grp the specified service queue belongs to
|
|
|
|
* @sq: the throtl_service_queue of interest
|
|
|
|
*
|
|
|
|
* Return the throtl_grp @sq belongs to. If @sq is the top-level one
|
|
|
|
* embedded in throtl_data, %NULL is returned.
|
|
|
|
*/
|
|
|
|
static struct throtl_grp *sq_to_tg(struct throtl_service_queue *sq)
|
|
|
|
{
|
|
|
|
if (sq && sq->parent_sq)
|
|
|
|
return container_of(sq, struct throtl_grp, service_queue);
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* sq_to_td - return throtl_data the specified service queue belongs to
|
|
|
|
* @sq: the throtl_service_queue of interest
|
|
|
|
*
|
2017-02-28 06:29:09 +08:00
|
|
|
* A service_queue can be embedded in either a throtl_grp or throtl_data.
|
2013-05-15 04:52:36 +08:00
|
|
|
* Determine the associated throtl_data accordingly and return it.
|
|
|
|
*/
|
|
|
|
static struct throtl_data *sq_to_td(struct throtl_service_queue *sq)
|
|
|
|
{
|
|
|
|
struct throtl_grp *tg = sq_to_tg(sq);
|
|
|
|
|
|
|
|
if (tg)
|
|
|
|
return tg->td;
|
|
|
|
else
|
|
|
|
return container_of(sq, struct throtl_data, service_queue);
|
|
|
|
}
|
|
|
|
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
/*
|
|
|
|
* cgroup's limit in LIMIT_MAX is scaled if low limit is set. This scale is to
|
|
|
|
* make the IO dispatch more smooth.
|
2022-12-05 19:57:06 +08:00
|
|
|
* Scale up: linearly scale up according to elapsed time since upgrade. For
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
* every throtl_slice, the limit scales up 1/2 .low limit till the
|
|
|
|
* limit hits .max limit
|
|
|
|
* Scale down: exponentially scale down if a cgroup doesn't hit its .low limit
|
|
|
|
*/
|
|
|
|
static uint64_t throtl_adjusted_limit(uint64_t low, struct throtl_data *td)
|
|
|
|
{
|
|
|
|
/* arbitrary value to avoid too big scale */
|
|
|
|
if (td->scale < 4096 && time_after_eq(jiffies,
|
|
|
|
td->low_upgrade_time + td->scale * td->throtl_slice))
|
|
|
|
td->scale = (jiffies - td->low_upgrade_time) / td->throtl_slice;
|
|
|
|
|
|
|
|
return low + (low >> 1) * td->scale;
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:30 +08:00
|
|
|
static uint64_t tg_bps_limit(struct throtl_grp *tg, int rw)
|
|
|
|
{
|
2017-03-28 01:51:33 +08:00
|
|
|
struct blkcg_gq *blkg = tg_to_blkg(tg);
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
struct throtl_data *td;
|
2017-03-28 01:51:33 +08:00
|
|
|
uint64_t ret;
|
|
|
|
|
|
|
|
if (cgroup_subsys_on_dfl(io_cgrp_subsys) && !blkg->parent)
|
|
|
|
return U64_MAX;
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
|
|
|
|
td = tg->td;
|
|
|
|
ret = tg->bps[rw][td->limit_index];
|
2017-05-18 04:07:26 +08:00
|
|
|
if (ret == 0 && td->limit_index == LIMIT_LOW) {
|
|
|
|
/* intermediate node or iops isn't 0 */
|
|
|
|
if (!list_empty(&blkg->blkcg->css.children) ||
|
|
|
|
tg->iops[rw][td->limit_index])
|
|
|
|
return U64_MAX;
|
|
|
|
else
|
|
|
|
return MIN_THROTL_BPS;
|
|
|
|
}
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
|
|
|
|
if (td->limit_index == LIMIT_MAX && tg->bps[rw][LIMIT_LOW] &&
|
|
|
|
tg->bps[rw][LIMIT_LOW] != tg->bps[rw][LIMIT_MAX]) {
|
|
|
|
uint64_t adjusted;
|
|
|
|
|
|
|
|
adjusted = throtl_adjusted_limit(tg->bps[rw][LIMIT_LOW], td);
|
|
|
|
ret = min(tg->bps[rw][LIMIT_MAX], adjusted);
|
|
|
|
}
|
2017-03-28 01:51:33 +08:00
|
|
|
return ret;
|
2017-03-28 01:51:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int tg_iops_limit(struct throtl_grp *tg, int rw)
|
|
|
|
{
|
2017-03-28 01:51:33 +08:00
|
|
|
struct blkcg_gq *blkg = tg_to_blkg(tg);
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
struct throtl_data *td;
|
2017-03-28 01:51:33 +08:00
|
|
|
unsigned int ret;
|
|
|
|
|
|
|
|
if (cgroup_subsys_on_dfl(io_cgrp_subsys) && !blkg->parent)
|
|
|
|
return UINT_MAX;
|
2017-05-18 04:07:26 +08:00
|
|
|
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
td = tg->td;
|
|
|
|
ret = tg->iops[rw][td->limit_index];
|
2017-05-18 04:07:26 +08:00
|
|
|
if (ret == 0 && tg->td->limit_index == LIMIT_LOW) {
|
|
|
|
/* intermediate node or bps isn't 0 */
|
|
|
|
if (!list_empty(&blkg->blkcg->css.children) ||
|
|
|
|
tg->bps[rw][td->limit_index])
|
|
|
|
return UINT_MAX;
|
|
|
|
else
|
|
|
|
return MIN_THROTL_IOPS;
|
|
|
|
}
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
|
|
|
|
if (td->limit_index == LIMIT_MAX && tg->iops[rw][LIMIT_LOW] &&
|
|
|
|
tg->iops[rw][LIMIT_LOW] != tg->iops[rw][LIMIT_MAX]) {
|
|
|
|
uint64_t adjusted;
|
|
|
|
|
|
|
|
adjusted = throtl_adjusted_limit(tg->iops[rw][LIMIT_LOW], td);
|
|
|
|
if (adjusted > UINT_MAX)
|
|
|
|
adjusted = UINT_MAX;
|
|
|
|
ret = min_t(unsigned int, tg->iops[rw][LIMIT_MAX], adjusted);
|
|
|
|
}
|
2017-03-28 01:51:33 +08:00
|
|
|
return ret;
|
2017-03-28 01:51:30 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
#define request_bucket_index(sectors) \
|
|
|
|
clamp_t(int, order_base_2(sectors) - 3, 0, LATENCY_BUCKET_SIZE - 1)
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
/**
|
|
|
|
* throtl_log - log debug message via blktrace
|
|
|
|
* @sq: the service_queue being reported
|
|
|
|
* @fmt: printf format string
|
|
|
|
* @args: printf args
|
|
|
|
*
|
|
|
|
* The messages are prefixed with "throtl BLKG_NAME" if @sq belongs to a
|
|
|
|
* throtl_grp; otherwise, just "throtl".
|
|
|
|
*/
|
|
|
|
#define throtl_log(sq, fmt, args...) do { \
|
|
|
|
struct throtl_grp *__tg = sq_to_tg((sq)); \
|
|
|
|
struct throtl_data *__td = sq_to_td((sq)); \
|
|
|
|
\
|
|
|
|
(void)__td; \
|
2016-05-10 08:22:15 +08:00
|
|
|
if (likely(!blk_trace_note_message_enabled(__td->queue))) \
|
|
|
|
break; \
|
2013-05-15 04:52:36 +08:00
|
|
|
if ((__tg)) { \
|
2017-07-13 02:49:56 +08:00
|
|
|
blk_add_cgroup_trace_msg(__td->queue, \
|
2022-04-20 12:27:16 +08:00
|
|
|
&tg_to_blkg(__tg)->blkcg->css, "throtl " fmt, ##args);\
|
2013-05-15 04:52:36 +08:00
|
|
|
} else { \
|
|
|
|
blk_add_trace_msg(__td->queue, "throtl " fmt, ##args); \
|
|
|
|
} \
|
2012-04-17 04:57:23 +08:00
|
|
|
} while (0)
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2017-08-19 07:08:13 +08:00
|
|
|
static inline unsigned int throtl_bio_data_size(struct bio *bio)
|
|
|
|
{
|
|
|
|
/* assume it's one sector */
|
|
|
|
if (unlikely(bio_op(bio) == REQ_OP_DISCARD))
|
|
|
|
return 512;
|
|
|
|
return bio->bi_iter.bi_size;
|
|
|
|
}
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
static void throtl_qnode_init(struct throtl_qnode *qn, struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
INIT_LIST_HEAD(&qn->node);
|
|
|
|
bio_list_init(&qn->bios);
|
|
|
|
qn->tg = tg;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* throtl_qnode_add_bio - add a bio to a throtl_qnode and activate it
|
|
|
|
* @bio: bio being added
|
|
|
|
* @qn: qnode to add bio to
|
|
|
|
* @queued: the service_queue->queued[] list @qn belongs to
|
|
|
|
*
|
|
|
|
* Add @bio to @qn and put @qn on @queued if it's not already on.
|
|
|
|
* @qn->tg's reference count is bumped when @qn is activated. See the
|
|
|
|
* comment on top of throtl_qnode definition for details.
|
|
|
|
*/
|
|
|
|
static void throtl_qnode_add_bio(struct bio *bio, struct throtl_qnode *qn,
|
|
|
|
struct list_head *queued)
|
|
|
|
{
|
|
|
|
bio_list_add(&qn->bios, bio);
|
|
|
|
if (list_empty(&qn->node)) {
|
|
|
|
list_add_tail(&qn->node, queued);
|
|
|
|
blkg_get(tg_to_blkg(qn->tg));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* throtl_peek_queued - peek the first bio on a qnode list
|
|
|
|
* @queued: the qnode list to peek
|
|
|
|
*/
|
|
|
|
static struct bio *throtl_peek_queued(struct list_head *queued)
|
|
|
|
{
|
2020-10-08 11:52:26 +08:00
|
|
|
struct throtl_qnode *qn;
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
if (list_empty(queued))
|
|
|
|
return NULL;
|
|
|
|
|
2020-10-08 11:52:26 +08:00
|
|
|
qn = list_first_entry(queued, struct throtl_qnode, node);
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
bio = bio_list_peek(&qn->bios);
|
|
|
|
WARN_ON_ONCE(!bio);
|
|
|
|
return bio;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* throtl_pop_queued - pop the first bio form a qnode list
|
|
|
|
* @queued: the qnode list to pop a bio from
|
|
|
|
* @tg_to_put: optional out argument for throtl_grp to put
|
|
|
|
*
|
|
|
|
* Pop the first bio from the qnode list @queued. After popping, the first
|
|
|
|
* qnode is removed from @queued if empty or moved to the end of @queued so
|
|
|
|
* that the popping order is round-robin.
|
|
|
|
*
|
|
|
|
* When the first qnode is removed, its associated throtl_grp should be put
|
|
|
|
* too. If @tg_to_put is NULL, this function automatically puts it;
|
|
|
|
* otherwise, *@tg_to_put is set to the throtl_grp to put and the caller is
|
|
|
|
* responsible for putting it.
|
|
|
|
*/
|
|
|
|
static struct bio *throtl_pop_queued(struct list_head *queued,
|
|
|
|
struct throtl_grp **tg_to_put)
|
|
|
|
{
|
2020-10-08 11:52:26 +08:00
|
|
|
struct throtl_qnode *qn;
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
if (list_empty(queued))
|
|
|
|
return NULL;
|
|
|
|
|
2020-10-08 11:52:26 +08:00
|
|
|
qn = list_first_entry(queued, struct throtl_qnode, node);
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
bio = bio_list_pop(&qn->bios);
|
|
|
|
WARN_ON_ONCE(!bio);
|
|
|
|
|
|
|
|
if (bio_list_empty(&qn->bios)) {
|
|
|
|
list_del_init(&qn->node);
|
|
|
|
if (tg_to_put)
|
|
|
|
*tg_to_put = qn->tg;
|
|
|
|
else
|
|
|
|
blkg_put(tg_to_blkg(qn->tg));
|
|
|
|
} else {
|
|
|
|
list_move_tail(&qn->node, queued);
|
|
|
|
}
|
|
|
|
|
|
|
|
return bio;
|
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:34 +08:00
|
|
|
/* init a service_queue, assumes the caller zeroed it */
|
2015-08-19 05:55:13 +08:00
|
|
|
static void throtl_service_queue_init(struct throtl_service_queue *sq)
|
2013-05-15 04:52:34 +08:00
|
|
|
{
|
2022-08-27 18:16:35 +08:00
|
|
|
INIT_LIST_HEAD(&sq->queued[READ]);
|
|
|
|
INIT_LIST_HEAD(&sq->queued[WRITE]);
|
2018-08-21 05:21:15 +08:00
|
|
|
sq->pending_tree = RB_ROOT_CACHED;
|
treewide: setup_timer() -> timer_setup()
This converts all remaining cases of the old setup_timer() API into using
timer_setup(), where the callback argument is the structure already
holding the struct timer_list. These should have no behavioral changes,
since they just change which pointer is passed into the callback with
the same available pointers after conversion. It handles the following
examples, in addition to some other variations.
Casting from unsigned long:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
setup_timer(&ptr->my_timer, my_callback, ptr);
and forced object casts:
void my_callback(struct something *ptr)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, (unsigned long)ptr);
become:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
Direct function assignments:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
ptr->my_timer.function = my_callback;
have a temporary cast added, along with converting the args:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
ptr->my_timer.function = (TIMER_FUNC_TYPE)my_callback;
And finally, callbacks without a data assignment:
void my_callback(unsigned long data)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, 0);
have their argument renamed to verify they're unused during conversion:
void my_callback(struct timer_list *unused)
{
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
The conversion is done with the following Coccinelle script:
spatch --very-quiet --all-includes --include-headers \
-I ./arch/x86/include -I ./arch/x86/include/generated \
-I ./include -I ./arch/x86/include/uapi \
-I ./arch/x86/include/generated/uapi -I ./include/uapi \
-I ./include/generated/uapi --include ./include/linux/kconfig.h \
--dir . \
--cocci-file ~/src/data/timer_setup.cocci
@fix_address_of@
expression e;
@@
setup_timer(
-&(e)
+&e
, ...)
// Update any raw setup_timer() usages that have a NULL callback, but
// would otherwise match change_timer_function_usage, since the latter
// will update all function assignments done in the face of a NULL
// function initialization in setup_timer().
@change_timer_function_usage_NULL@
expression _E;
identifier _timer;
type _cast_data;
@@
(
-setup_timer(&_E->_timer, NULL, _E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E->_timer, NULL, (_cast_data)_E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, &_E);
+timer_setup(&_E._timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, (_cast_data)&_E);
+timer_setup(&_E._timer, NULL, 0);
)
@change_timer_function_usage@
expression _E;
identifier _timer;
struct timer_list _stl;
identifier _callback;
type _cast_func, _cast_data;
@@
(
-setup_timer(&_E->_timer, _callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
_E->_timer@_stl.function = _callback;
|
_E->_timer@_stl.function = &_callback;
|
_E->_timer@_stl.function = (_cast_func)_callback;
|
_E->_timer@_stl.function = (_cast_func)&_callback;
|
_E._timer@_stl.function = _callback;
|
_E._timer@_stl.function = &_callback;
|
_E._timer@_stl.function = (_cast_func)_callback;
|
_E._timer@_stl.function = (_cast_func)&_callback;
)
// callback(unsigned long arg)
@change_callback_handle_cast
depends on change_timer_function_usage@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
identifier _handle;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
(
... when != _origarg
_handletype *_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
)
}
// callback(unsigned long arg) without existing variable
@change_callback_handle_cast_no_arg
depends on change_timer_function_usage &&
!change_callback_handle_cast@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
+ _handletype *_origarg = from_timer(_origarg, t, _timer);
+
... when != _origarg
- (_handletype *)_origarg
+ _origarg
... when != _origarg
}
// Avoid already converted callbacks.
@match_callback_converted
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier t;
@@
void _callback(struct timer_list *t)
{ ... }
// callback(struct something *handle)
@change_callback_handle_arg
depends on change_timer_function_usage &&
!match_callback_converted &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
@@
void _callback(
-_handletype *_handle
+struct timer_list *t
)
{
+ _handletype *_handle = from_timer(_handle, t, _timer);
...
}
// If change_callback_handle_arg ran on an empty function, remove
// the added handler.
@unchange_callback_handle_arg
depends on change_timer_function_usage &&
change_callback_handle_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
identifier t;
@@
void _callback(struct timer_list *t)
{
- _handletype *_handle = from_timer(_handle, t, _timer);
}
// We only want to refactor the setup_timer() data argument if we've found
// the matching callback. This undoes changes in change_timer_function_usage.
@unchange_timer_function_usage
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg &&
!change_callback_handle_arg@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type change_timer_function_usage._cast_data;
@@
(
-timer_setup(&_E->_timer, _callback, 0);
+setup_timer(&_E->_timer, _callback, (_cast_data)_E);
|
-timer_setup(&_E._timer, _callback, 0);
+setup_timer(&_E._timer, _callback, (_cast_data)&_E);
)
// If we fixed a callback from a .function assignment, fix the
// assignment cast now.
@change_timer_function_assignment
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_func;
typedef TIMER_FUNC_TYPE;
@@
(
_E->_timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-&_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
)
// Sometimes timer functions are called directly. Replace matched args.
@change_timer_function_calls
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression _E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_data;
@@
_callback(
(
-(_cast_data)_E
+&_E->_timer
|
-(_cast_data)&_E
+&_E._timer
|
-_E
+&_E->_timer
)
)
// If a timer has been configured without a data argument, it can be
// converted without regard to the callback argument, since it is unused.
@match_timer_function_unused_data@
expression _E;
identifier _timer;
identifier _callback;
@@
(
-setup_timer(&_E->_timer, _callback, 0);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0L);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0UL);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0L);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0UL);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0L);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0UL);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0L);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0UL);
+timer_setup(_timer, _callback, 0);
)
@change_callback_unused_data
depends on match_timer_function_unused_data@
identifier match_timer_function_unused_data._callback;
type _origtype;
identifier _origarg;
@@
void _callback(
-_origtype _origarg
+struct timer_list *unused
)
{
... when != _origarg
}
Signed-off-by: Kees Cook <keescook@chromium.org>
2017-10-17 05:43:17 +08:00
|
|
|
timer_setup(&sq->pending_timer, throtl_pending_timer_fn, 0);
|
2013-05-15 04:52:36 +08:00
|
|
|
}
|
|
|
|
|
2023-02-03 23:03:58 +08:00
|
|
|
static struct blkg_policy_data *throtl_pd_alloc(struct gendisk *disk,
|
|
|
|
struct blkcg *blkcg, gfp_t gfp)
|
2015-08-19 05:55:11 +08:00
|
|
|
{
|
2015-08-19 05:55:12 +08:00
|
|
|
struct throtl_grp *tg;
|
2015-08-19 05:55:22 +08:00
|
|
|
int rw;
|
2015-08-19 05:55:12 +08:00
|
|
|
|
2023-02-03 23:03:58 +08:00
|
|
|
tg = kzalloc_node(sizeof(*tg), gfp, disk->node_id);
|
2015-08-19 05:55:12 +08:00
|
|
|
if (!tg)
|
2015-08-19 05:55:24 +08:00
|
|
|
return NULL;
|
2015-08-19 05:55:12 +08:00
|
|
|
|
2019-11-08 03:18:01 +08:00
|
|
|
if (blkg_rwstat_init(&tg->stat_bytes, gfp))
|
|
|
|
goto err_free_tg;
|
|
|
|
|
|
|
|
if (blkg_rwstat_init(&tg->stat_ios, gfp))
|
|
|
|
goto err_exit_stat_bytes;
|
|
|
|
|
2015-08-19 05:55:13 +08:00
|
|
|
throtl_service_queue_init(&tg->service_queue);
|
|
|
|
|
|
|
|
for (rw = READ; rw <= WRITE; rw++) {
|
|
|
|
throtl_qnode_init(&tg->qnode_on_self[rw], tg);
|
|
|
|
throtl_qnode_init(&tg->qnode_on_parent[rw], tg);
|
|
|
|
}
|
|
|
|
|
|
|
|
RB_CLEAR_NODE(&tg->rb_node);
|
2017-03-28 01:51:30 +08:00
|
|
|
tg->bps[READ][LIMIT_MAX] = U64_MAX;
|
|
|
|
tg->bps[WRITE][LIMIT_MAX] = U64_MAX;
|
|
|
|
tg->iops[READ][LIMIT_MAX] = UINT_MAX;
|
|
|
|
tg->iops[WRITE][LIMIT_MAX] = UINT_MAX;
|
2017-03-28 01:51:32 +08:00
|
|
|
tg->bps_conf[READ][LIMIT_MAX] = U64_MAX;
|
|
|
|
tg->bps_conf[WRITE][LIMIT_MAX] = U64_MAX;
|
|
|
|
tg->iops_conf[READ][LIMIT_MAX] = UINT_MAX;
|
|
|
|
tg->iops_conf[WRITE][LIMIT_MAX] = UINT_MAX;
|
|
|
|
/* LIMIT_LOW will have default value 0 */
|
2015-08-19 05:55:13 +08:00
|
|
|
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
tg->latency_target = DFL_LATENCY_TARGET;
|
2017-05-18 04:07:24 +08:00
|
|
|
tg->latency_target_conf = DFL_LATENCY_TARGET;
|
2017-05-18 04:07:27 +08:00
|
|
|
tg->idletime_threshold = DFL_IDLE_THRESHOLD;
|
|
|
|
tg->idletime_threshold_conf = DFL_IDLE_THRESHOLD;
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
|
2015-08-19 05:55:12 +08:00
|
|
|
return &tg->pd;
|
2019-11-08 03:18:01 +08:00
|
|
|
|
|
|
|
err_exit_stat_bytes:
|
|
|
|
blkg_rwstat_exit(&tg->stat_bytes);
|
|
|
|
err_free_tg:
|
|
|
|
kfree(tg);
|
|
|
|
return NULL;
|
2015-08-19 05:55:11 +08:00
|
|
|
}
|
|
|
|
|
2015-08-19 05:55:14 +08:00
|
|
|
static void throtl_pd_init(struct blkg_policy_data *pd)
|
2011-05-20 03:38:19 +08:00
|
|
|
{
|
2015-08-19 05:55:14 +08:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
struct blkcg_gq *blkg = tg_to_blkg(tg);
|
2023-02-15 02:33:08 +08:00
|
|
|
struct throtl_data *td = blkg->q->td;
|
2015-08-19 05:55:13 +08:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2012-03-06 05:15:06 +08:00
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
/*
|
2014-07-09 22:08:08 +08:00
|
|
|
* If on the default hierarchy, we switch to properly hierarchical
|
2013-05-15 04:52:38 +08:00
|
|
|
* behavior where limits on a given throtl_grp are applied to the
|
|
|
|
* whole subtree rather than just the group itself. e.g. If 16M
|
2022-12-05 19:57:01 +08:00
|
|
|
* read_bps limit is set on a parent group, summary bps of
|
|
|
|
* parent group and its subtree groups can't exceed 16M for the
|
|
|
|
* device.
|
2013-05-15 04:52:38 +08:00
|
|
|
*
|
2014-07-09 22:08:08 +08:00
|
|
|
* If not on the default hierarchy, the broken flat hierarchy
|
2013-05-15 04:52:38 +08:00
|
|
|
* behavior is retained where all throtl_grps are treated as if
|
|
|
|
* they're all separate root groups right below throtl_data.
|
|
|
|
* Limits of a group don't interact with limits of other groups
|
|
|
|
* regardless of the position of the group in the hierarchy.
|
|
|
|
*/
|
2015-08-19 05:55:13 +08:00
|
|
|
sq->parent_sq = &td->service_queue;
|
2015-09-18 23:56:28 +08:00
|
|
|
if (cgroup_subsys_on_dfl(io_cgrp_subsys) && blkg->parent)
|
2015-08-19 05:55:13 +08:00
|
|
|
sq->parent_sq = &blkg_to_tg(blkg->parent)->service_queue;
|
2013-05-15 04:52:36 +08:00
|
|
|
tg->td = td;
|
2012-04-02 05:38:44 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
/*
|
|
|
|
* Set has_rules[] if @tg or any of its parents have limits configured.
|
|
|
|
* This doesn't require walking up to the top of the hierarchy as the
|
|
|
|
* parent's has_rules[] is guaranteed to be correct.
|
|
|
|
*/
|
|
|
|
static void tg_update_has_rules(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
struct throtl_grp *parent_tg = sq_to_tg(tg->service_queue.parent_sq);
|
2017-03-28 01:51:30 +08:00
|
|
|
struct throtl_data *td = tg->td;
|
2013-05-15 04:52:38 +08:00
|
|
|
int rw;
|
|
|
|
|
2022-09-21 17:53:09 +08:00
|
|
|
for (rw = READ; rw <= WRITE; rw++) {
|
|
|
|
tg->has_rules_iops[rw] =
|
|
|
|
(parent_tg && parent_tg->has_rules_iops[rw]) ||
|
|
|
|
(td->limit_valid[td->limit_index] &&
|
|
|
|
tg_iops_limit(tg, rw) != UINT_MAX);
|
|
|
|
tg->has_rules_bps[rw] =
|
|
|
|
(parent_tg && parent_tg->has_rules_bps[rw]) ||
|
2017-03-28 01:51:30 +08:00
|
|
|
(td->limit_valid[td->limit_index] &&
|
2022-09-21 17:53:09 +08:00
|
|
|
(tg_bps_limit(tg, rw) != U64_MAX));
|
|
|
|
}
|
2013-05-15 04:52:38 +08:00
|
|
|
}
|
|
|
|
|
2015-08-19 05:55:14 +08:00
|
|
|
static void throtl_pd_online(struct blkg_policy_data *pd)
|
2013-05-15 04:52:38 +08:00
|
|
|
{
|
2017-03-28 01:51:39 +08:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
2013-05-15 04:52:38 +08:00
|
|
|
/*
|
|
|
|
* We don't want new groups to escape the limits of its ancestors.
|
|
|
|
* Update has_rules[] after a new group is brought online.
|
|
|
|
*/
|
2017-03-28 01:51:39 +08:00
|
|
|
tg_update_has_rules(tg);
|
2013-05-15 04:52:38 +08:00
|
|
|
}
|
|
|
|
|
2020-11-26 11:18:34 +08:00
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
2017-03-28 01:51:32 +08:00
|
|
|
static void blk_throtl_update_limit_valid(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
struct cgroup_subsys_state *pos_css;
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
bool low_valid = false;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2023-02-15 02:33:04 +08:00
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg) {
|
2017-03-28 01:51:32 +08:00
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg);
|
|
|
|
|
|
|
|
if (tg->bps[READ][LIMIT_LOW] || tg->bps[WRITE][LIMIT_LOW] ||
|
2018-06-29 09:56:56 +08:00
|
|
|
tg->iops[READ][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW]) {
|
2017-03-28 01:51:32 +08:00
|
|
|
low_valid = true;
|
2018-06-29 09:56:56 +08:00
|
|
|
break;
|
|
|
|
}
|
2017-03-28 01:51:32 +08:00
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
td->limit_valid[LIMIT_LOW] = low_valid;
|
|
|
|
}
|
2020-11-26 11:18:34 +08:00
|
|
|
#else
|
|
|
|
static inline void blk_throtl_update_limit_valid(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
2017-03-28 01:51:32 +08:00
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
static void throtl_upgrade_state(struct throtl_data *td);
|
2017-03-28 01:51:32 +08:00
|
|
|
static void throtl_pd_offline(struct blkg_policy_data *pd)
|
|
|
|
{
|
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
|
|
|
|
tg->bps[READ][LIMIT_LOW] = 0;
|
|
|
|
tg->bps[WRITE][LIMIT_LOW] = 0;
|
|
|
|
tg->iops[READ][LIMIT_LOW] = 0;
|
|
|
|
tg->iops[WRITE][LIMIT_LOW] = 0;
|
|
|
|
|
|
|
|
blk_throtl_update_limit_valid(tg->td);
|
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
if (!tg->td->limit_valid[tg->td->limit_index])
|
|
|
|
throtl_upgrade_state(tg->td);
|
2017-03-28 01:51:32 +08:00
|
|
|
}
|
|
|
|
|
2015-08-19 05:55:11 +08:00
|
|
|
static void throtl_pd_free(struct blkg_policy_data *pd)
|
|
|
|
{
|
2015-08-19 05:55:12 +08:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
|
2015-08-19 05:55:13 +08:00
|
|
|
del_timer_sync(&tg->service_queue.pending_timer);
|
2019-11-08 03:18:01 +08:00
|
|
|
blkg_rwstat_exit(&tg->stat_bytes);
|
|
|
|
blkg_rwstat_exit(&tg->stat_ios);
|
2015-08-19 05:55:12 +08:00
|
|
|
kfree(tg);
|
2015-08-19 05:55:11 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:33 +08:00
|
|
|
static struct throtl_grp *
|
|
|
|
throtl_rb_first(struct throtl_service_queue *parent_sq)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2018-08-21 05:21:15 +08:00
|
|
|
struct rb_node *n;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2018-08-21 05:21:15 +08:00
|
|
|
n = rb_first_cached(&parent_sq->pending_tree);
|
|
|
|
WARN_ON_ONCE(!n);
|
|
|
|
if (!n)
|
|
|
|
return NULL;
|
|
|
|
return rb_entry_tg(n);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:33 +08:00
|
|
|
static void throtl_rb_erase(struct rb_node *n,
|
|
|
|
struct throtl_service_queue *parent_sq)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2018-08-21 05:21:15 +08:00
|
|
|
rb_erase_cached(n, &parent_sq->pending_tree);
|
|
|
|
RB_CLEAR_NODE(n);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:33 +08:00
|
|
|
static void update_min_dispatch_time(struct throtl_service_queue *parent_sq)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
|
|
|
struct throtl_grp *tg;
|
|
|
|
|
2013-05-15 04:52:33 +08:00
|
|
|
tg = throtl_rb_first(parent_sq);
|
2010-09-16 05:06:35 +08:00
|
|
|
if (!tg)
|
|
|
|
return;
|
|
|
|
|
2013-05-15 04:52:33 +08:00
|
|
|
parent_sq->first_pending_disptime = tg->disptime;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
static void tg_service_queue_add(struct throtl_grp *tg)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2013-05-15 04:52:36 +08:00
|
|
|
struct throtl_service_queue *parent_sq = tg->service_queue.parent_sq;
|
2018-08-21 05:21:15 +08:00
|
|
|
struct rb_node **node = &parent_sq->pending_tree.rb_root.rb_node;
|
2010-09-16 05:06:35 +08:00
|
|
|
struct rb_node *parent = NULL;
|
|
|
|
struct throtl_grp *__tg;
|
|
|
|
unsigned long key = tg->disptime;
|
2018-08-21 05:21:15 +08:00
|
|
|
bool leftmost = true;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
while (*node != NULL) {
|
|
|
|
parent = *node;
|
|
|
|
__tg = rb_entry_tg(parent);
|
|
|
|
|
|
|
|
if (time_before(key, __tg->disptime))
|
|
|
|
node = &parent->rb_left;
|
|
|
|
else {
|
|
|
|
node = &parent->rb_right;
|
2018-08-21 05:21:15 +08:00
|
|
|
leftmost = false;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rb_link_node(&tg->rb_node, parent, node);
|
2018-08-21 05:21:15 +08:00
|
|
|
rb_insert_color_cached(&tg->rb_node, &parent_sq->pending_tree,
|
|
|
|
leftmost);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
static void throtl_enqueue_tg(struct throtl_grp *tg)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2020-10-08 11:52:28 +08:00
|
|
|
if (!(tg->flags & THROTL_TG_PENDING)) {
|
|
|
|
tg_service_queue_add(tg);
|
|
|
|
tg->flags |= THROTL_TG_PENDING;
|
|
|
|
tg->service_queue.parent_sq->nr_pending++;
|
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
static void throtl_dequeue_tg(struct throtl_grp *tg)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2020-10-08 11:52:28 +08:00
|
|
|
if (tg->flags & THROTL_TG_PENDING) {
|
2022-08-27 18:16:37 +08:00
|
|
|
struct throtl_service_queue *parent_sq =
|
|
|
|
tg->service_queue.parent_sq;
|
|
|
|
|
|
|
|
throtl_rb_erase(&tg->rb_node, parent_sq);
|
|
|
|
--parent_sq->nr_pending;
|
2020-10-08 11:52:28 +08:00
|
|
|
tg->flags &= ~THROTL_TG_PENDING;
|
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:31 +08:00
|
|
|
/* Call with queue lock held */
|
2013-05-15 04:52:36 +08:00
|
|
|
static void throtl_schedule_pending_timer(struct throtl_service_queue *sq,
|
|
|
|
unsigned long expires)
|
2013-05-15 04:52:31 +08:00
|
|
|
{
|
2017-06-07 11:36:14 +08:00
|
|
|
unsigned long max_expire = jiffies + 8 * sq_to_td(sq)->throtl_slice;
|
2017-03-28 01:51:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since we are adjusting the throttle limit dynamically, the sleep
|
|
|
|
* time calculated according to previous limit might be invalid. It's
|
|
|
|
* possible the cgroup sleep time is very long and no other cgroups
|
|
|
|
* have IO running so notify the limit changes. Make sure the cgroup
|
|
|
|
* doesn't sleep too long to avoid the missed notification.
|
|
|
|
*/
|
|
|
|
if (time_after(expires, max_expire))
|
|
|
|
expires = max_expire;
|
2013-05-15 04:52:36 +08:00
|
|
|
mod_timer(&sq->pending_timer, expires);
|
|
|
|
throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu",
|
|
|
|
expires - jiffies, jiffies);
|
2013-05-15 04:52:31 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
/**
|
|
|
|
* throtl_schedule_next_dispatch - schedule the next dispatch cycle
|
|
|
|
* @sq: the service_queue to schedule dispatch for
|
|
|
|
* @force: force scheduling
|
|
|
|
*
|
|
|
|
* Arm @sq->pending_timer so that the next dispatch cycle starts on the
|
|
|
|
* dispatch time of the first pending child. Returns %true if either timer
|
|
|
|
* is armed or there's no pending child left. %false if the current
|
|
|
|
* dispatch window is still open and the caller should continue
|
|
|
|
* dispatching.
|
|
|
|
*
|
|
|
|
* If @force is %true, the dispatch timer is always scheduled and this
|
|
|
|
* function is guaranteed to return %true. This is to be used when the
|
|
|
|
* caller can't dispatch itself and needs to invoke pending_timer
|
|
|
|
* unconditionally. Note that forced scheduling is likely to induce short
|
|
|
|
* delay before dispatch starts even if @sq->first_pending_disptime is not
|
|
|
|
* in the future and thus shouldn't be used in hot paths.
|
|
|
|
*/
|
|
|
|
static bool throtl_schedule_next_dispatch(struct throtl_service_queue *sq,
|
|
|
|
bool force)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2013-05-15 04:52:32 +08:00
|
|
|
/* any pending children left? */
|
2013-05-15 04:52:32 +08:00
|
|
|
if (!sq->nr_pending)
|
2013-05-15 04:52:37 +08:00
|
|
|
return true;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:32 +08:00
|
|
|
update_min_dispatch_time(sq);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
/* is the next dispatch time in the future? */
|
2013-05-15 04:52:37 +08:00
|
|
|
if (force || time_after(sq->first_pending_disptime, jiffies)) {
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_schedule_pending_timer(sq, sq->first_pending_disptime);
|
2013-05-15 04:52:37 +08:00
|
|
|
return true;
|
2013-05-15 04:52:36 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
/* tell the caller to continue dispatching */
|
|
|
|
return false;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: Account for child group's start time in parent while bio climbs up
With the planned proper hierarchy support, a bio will climb up the
tree before actually being dispatched. This makes sure bio is also
subjected to parent's throttling limits, if any.
It might happen that parent is idle and when bio is transferred to
parent, a new slice starts fresh. But that is incorrect as parents
wait time should have started when bio was queued in child group and
causes IOs to be throttled more than configured as they climb the
hierarchy.
Given the fact that we have not written hierarchical algorithm in a
way where child's and parents time slices are synchronized, we
transfer the child's start time to parent if parent was idling. If
parent was busy doing dispatch of other bios all this while, this is
not an issue.
Child's slice start time is passed to parent. Parent looks at its
last expired slice start time. If child's start time is after parents
old start time, that means parent had been idle and after parent
went idle, child had an IO queued. So use child's start time as
parent start time.
If parent's start time is after child's start time, that means,
when IO got queued in child group, parent was not idle. But later
it dispatched some IO, its slice got trimmed and then it went idle.
After a while child's request got shifted in parent group. In this
case use parent's old start time as new start time as that's the
duration of slice we did not use.
This logic is far from perfect as if there are multiple childs
then first child transferring the bio decides the start time while
a bio might have queued up even earlier in other child, which is
yet to be transferred up to parent. In that case we will lose
time and bandwidth in parent. This patch is just an approximation
to make situation somewhat better.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-05-15 04:52:38 +08:00
|
|
|
static inline void throtl_start_new_slice_with_credit(struct throtl_grp *tg,
|
|
|
|
bool rw, unsigned long start)
|
|
|
|
{
|
|
|
|
tg->bytes_disp[rw] = 0;
|
|
|
|
tg->io_disp[rw] = 0;
|
2022-08-29 10:22:40 +08:00
|
|
|
tg->carryover_bytes[rw] = 0;
|
|
|
|
tg->carryover_ios[rw] = 0;
|
blk-throttle: Account for child group's start time in parent while bio climbs up
With the planned proper hierarchy support, a bio will climb up the
tree before actually being dispatched. This makes sure bio is also
subjected to parent's throttling limits, if any.
It might happen that parent is idle and when bio is transferred to
parent, a new slice starts fresh. But that is incorrect as parents
wait time should have started when bio was queued in child group and
causes IOs to be throttled more than configured as they climb the
hierarchy.
Given the fact that we have not written hierarchical algorithm in a
way where child's and parents time slices are synchronized, we
transfer the child's start time to parent if parent was idling. If
parent was busy doing dispatch of other bios all this while, this is
not an issue.
Child's slice start time is passed to parent. Parent looks at its
last expired slice start time. If child's start time is after parents
old start time, that means parent had been idle and after parent
went idle, child had an IO queued. So use child's start time as
parent start time.
If parent's start time is after child's start time, that means,
when IO got queued in child group, parent was not idle. But later
it dispatched some IO, its slice got trimmed and then it went idle.
After a while child's request got shifted in parent group. In this
case use parent's old start time as new start time as that's the
duration of slice we did not use.
This logic is far from perfect as if there are multiple childs
then first child transferring the bio decides the start time while
a bio might have queued up even earlier in other child, which is
yet to be transferred up to parent. In that case we will lose
time and bandwidth in parent. This patch is just an approximation
to make situation somewhat better.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-05-15 04:52:38 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Previous slice has expired. We must have trimmed it after last
|
|
|
|
* bio dispatch. That means since start of last slice, we never used
|
|
|
|
* that bandwidth. Do try to make use of that bandwidth while giving
|
|
|
|
* credit.
|
|
|
|
*/
|
2022-12-05 19:57:09 +08:00
|
|
|
if (time_after(start, tg->slice_start[rw]))
|
blk-throttle: Account for child group's start time in parent while bio climbs up
With the planned proper hierarchy support, a bio will climb up the
tree before actually being dispatched. This makes sure bio is also
subjected to parent's throttling limits, if any.
It might happen that parent is idle and when bio is transferred to
parent, a new slice starts fresh. But that is incorrect as parents
wait time should have started when bio was queued in child group and
causes IOs to be throttled more than configured as they climb the
hierarchy.
Given the fact that we have not written hierarchical algorithm in a
way where child's and parents time slices are synchronized, we
transfer the child's start time to parent if parent was idling. If
parent was busy doing dispatch of other bios all this while, this is
not an issue.
Child's slice start time is passed to parent. Parent looks at its
last expired slice start time. If child's start time is after parents
old start time, that means parent had been idle and after parent
went idle, child had an IO queued. So use child's start time as
parent start time.
If parent's start time is after child's start time, that means,
when IO got queued in child group, parent was not idle. But later
it dispatched some IO, its slice got trimmed and then it went idle.
After a while child's request got shifted in parent group. In this
case use parent's old start time as new start time as that's the
duration of slice we did not use.
This logic is far from perfect as if there are multiple childs
then first child transferring the bio decides the start time while
a bio might have queued up even earlier in other child, which is
yet to be transferred up to parent. In that case we will lose
time and bandwidth in parent. This patch is just an approximation
to make situation somewhat better.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-05-15 04:52:38 +08:00
|
|
|
tg->slice_start[rw] = start;
|
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
tg->slice_end[rw] = jiffies + tg->td->throtl_slice;
|
blk-throttle: Account for child group's start time in parent while bio climbs up
With the planned proper hierarchy support, a bio will climb up the
tree before actually being dispatched. This makes sure bio is also
subjected to parent's throttling limits, if any.
It might happen that parent is idle and when bio is transferred to
parent, a new slice starts fresh. But that is incorrect as parents
wait time should have started when bio was queued in child group and
causes IOs to be throttled more than configured as they climb the
hierarchy.
Given the fact that we have not written hierarchical algorithm in a
way where child's and parents time slices are synchronized, we
transfer the child's start time to parent if parent was idling. If
parent was busy doing dispatch of other bios all this while, this is
not an issue.
Child's slice start time is passed to parent. Parent looks at its
last expired slice start time. If child's start time is after parents
old start time, that means parent had been idle and after parent
went idle, child had an IO queued. So use child's start time as
parent start time.
If parent's start time is after child's start time, that means,
when IO got queued in child group, parent was not idle. But later
it dispatched some IO, its slice got trimmed and then it went idle.
After a while child's request got shifted in parent group. In this
case use parent's old start time as new start time as that's the
duration of slice we did not use.
This logic is far from perfect as if there are multiple childs
then first child transferring the bio decides the start time while
a bio might have queued up even earlier in other child, which is
yet to be transferred up to parent. In that case we will lose
time and bandwidth in parent. This patch is just an approximation
to make situation somewhat better.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-05-15 04:52:38 +08:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"[%c] new slice with credit start=%lu end=%lu jiffies=%lu",
|
|
|
|
rw == READ ? 'R' : 'W', tg->slice_start[rw],
|
|
|
|
tg->slice_end[rw], jiffies);
|
|
|
|
}
|
|
|
|
|
2022-08-29 10:22:40 +08:00
|
|
|
static inline void throtl_start_new_slice(struct throtl_grp *tg, bool rw,
|
|
|
|
bool clear_carryover)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
|
|
|
tg->bytes_disp[rw] = 0;
|
2010-09-16 05:06:37 +08:00
|
|
|
tg->io_disp[rw] = 0;
|
2010-09-16 05:06:35 +08:00
|
|
|
tg->slice_start[rw] = jiffies;
|
2017-03-28 01:51:37 +08:00
|
|
|
tg->slice_end[rw] = jiffies + tg->td->throtl_slice;
|
2022-08-29 10:22:40 +08:00
|
|
|
if (clear_carryover) {
|
|
|
|
tg->carryover_bytes[rw] = 0;
|
|
|
|
tg->carryover_ios[rw] = 0;
|
|
|
|
}
|
2021-08-02 11:51:56 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"[%c] new slice start=%lu end=%lu jiffies=%lu",
|
|
|
|
rw == READ ? 'R' : 'W', tg->slice_start[rw],
|
|
|
|
tg->slice_end[rw], jiffies);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:32 +08:00
|
|
|
static inline void throtl_set_slice_end(struct throtl_grp *tg, bool rw,
|
|
|
|
unsigned long jiffy_end)
|
2010-12-02 02:34:46 +08:00
|
|
|
{
|
2017-03-28 01:51:37 +08:00
|
|
|
tg->slice_end[rw] = roundup(jiffy_end, tg->td->throtl_slice);
|
2010-12-02 02:34:46 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:32 +08:00
|
|
|
static inline void throtl_extend_slice(struct throtl_grp *tg, bool rw,
|
|
|
|
unsigned long jiffy_end)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2020-10-08 11:52:29 +08:00
|
|
|
throtl_set_slice_end(tg, rw, jiffy_end);
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"[%c] extend slice start=%lu end=%lu jiffies=%lu",
|
|
|
|
rw == READ ? 'R' : 'W', tg->slice_start[rw],
|
|
|
|
tg->slice_end[rw], jiffies);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Determine if previously allocated or extended slice is complete or not */
|
2013-05-15 04:52:32 +08:00
|
|
|
static bool throtl_slice_used(struct throtl_grp *tg, bool rw)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
|
|
|
if (time_in_range(jiffies, tg->slice_start[rw], tg->slice_end[rw]))
|
2014-05-03 00:28:17 +08:00
|
|
|
return false;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2018-05-29 18:32:44 +08:00
|
|
|
return true;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2023-08-16 09:27:07 +08:00
|
|
|
static unsigned int calculate_io_allowed(u32 iops_limit,
|
|
|
|
unsigned long jiffy_elapsed)
|
|
|
|
{
|
|
|
|
unsigned int io_allowed;
|
|
|
|
u64 tmp;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* jiffy_elapsed should not be a big value as minimum iops can be
|
|
|
|
* 1 then at max jiffy elapsed should be equivalent of 1 second as we
|
|
|
|
* will allow dispatch after 1 second and after that slice should
|
|
|
|
* have been trimmed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
tmp = (u64)iops_limit * jiffy_elapsed;
|
|
|
|
do_div(tmp, HZ);
|
|
|
|
|
|
|
|
if (tmp > UINT_MAX)
|
|
|
|
io_allowed = UINT_MAX;
|
|
|
|
else
|
|
|
|
io_allowed = tmp;
|
|
|
|
|
|
|
|
return io_allowed;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 calculate_bytes_allowed(u64 bps_limit, unsigned long jiffy_elapsed)
|
|
|
|
{
|
2023-10-21 06:36:17 +08:00
|
|
|
/*
|
|
|
|
* Can result be wider than 64 bits?
|
|
|
|
* We check against 62, not 64, due to ilog2 truncation.
|
|
|
|
*/
|
|
|
|
if (ilog2(bps_limit) + ilog2(jiffy_elapsed) - ilog2(HZ) > 62)
|
|
|
|
return U64_MAX;
|
2023-08-16 09:27:07 +08:00
|
|
|
return mul_u64_u64_div_u64(bps_limit, (u64)jiffy_elapsed, (u64)HZ);
|
|
|
|
}
|
|
|
|
|
2010-09-16 05:06:35 +08:00
|
|
|
/* Trim the used slices and adjust slice start accordingly */
|
2013-05-15 04:52:32 +08:00
|
|
|
static inline void throtl_trim_slice(struct throtl_grp *tg, bool rw)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
blk-throttle: consider 'carryover_ios/bytes' in throtl_trim_slice()
Currently, 'carryover_ios/bytes' is not handled in throtl_trim_slice(),
for consequence, 'carryover_ios/bytes' will be used to throttle bio
multiple times, for example:
1) set iops limit to 100, and slice start is 0, slice end is 100ms;
2) current time is 0, and 10 ios are dispatched, those io won't be
throttled and io_disp is 10;
3) still at current time 0, update iops limit to 1000, carryover_ios is
updated to (0 - 10) = -10;
4) in this slice(0 - 100ms), io_allowed = 100 + (-10) = 90, which means
only 90 ios can be dispatched without waiting;
5) assume that io is throttled in slice(0 - 100ms), and
throtl_trim_slice() update silce to (100ms - 200ms). In this case,
'carryover_ios/bytes' is not cleared and still only 90 ios can be
dispatched between 100ms - 200ms.
Fix this problem by updating 'carryover_ios/bytes' in
throtl_trim_slice().
Fixes: a880ae93e5b5 ("blk-throttle: fix io hung due to configuration updates")
Reported-by: zhuxiaohui <zhuxiaohui.400@bytedance.com>
Link: https://lore.kernel.org/all/20230812072116.42321-1-zhuxiaohui.400@bytedance.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-5-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:08 +08:00
|
|
|
unsigned long time_elapsed;
|
|
|
|
long long bytes_trim;
|
|
|
|
int io_trim;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
BUG_ON(time_before(tg->slice_end[rw], tg->slice_start[rw]));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If bps are unlimited (-1), then time slice don't get
|
|
|
|
* renewed. Don't try to trim the slice if slice is used. A new
|
|
|
|
* slice will start when appropriate.
|
|
|
|
*/
|
2013-05-15 04:52:32 +08:00
|
|
|
if (throtl_slice_used(tg, rw))
|
2010-09-16 05:06:35 +08:00
|
|
|
return;
|
|
|
|
|
2010-12-02 02:34:46 +08:00
|
|
|
/*
|
|
|
|
* A bio has been dispatched. Also adjust slice_end. It might happen
|
|
|
|
* that initially cgroup limit was very low resulting in high
|
2020-09-07 16:10:13 +08:00
|
|
|
* slice_end, but later limit was bumped up and bio was dispatched
|
2010-12-02 02:34:46 +08:00
|
|
|
* sooner, then we need to reduce slice_end. A high bogus slice_end
|
|
|
|
* is bad because it does not allow new slice to start.
|
|
|
|
*/
|
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
throtl_set_slice_end(tg, rw, jiffies + tg->td->throtl_slice);
|
2010-12-02 02:34:46 +08:00
|
|
|
|
2023-08-16 09:27:07 +08:00
|
|
|
time_elapsed = rounddown(jiffies - tg->slice_start[rw],
|
|
|
|
tg->td->throtl_slice);
|
|
|
|
if (!time_elapsed)
|
2010-09-16 05:06:35 +08:00
|
|
|
return;
|
|
|
|
|
2023-08-16 09:27:07 +08:00
|
|
|
bytes_trim = calculate_bytes_allowed(tg_bps_limit(tg, rw),
|
blk-throttle: consider 'carryover_ios/bytes' in throtl_trim_slice()
Currently, 'carryover_ios/bytes' is not handled in throtl_trim_slice(),
for consequence, 'carryover_ios/bytes' will be used to throttle bio
multiple times, for example:
1) set iops limit to 100, and slice start is 0, slice end is 100ms;
2) current time is 0, and 10 ios are dispatched, those io won't be
throttled and io_disp is 10;
3) still at current time 0, update iops limit to 1000, carryover_ios is
updated to (0 - 10) = -10;
4) in this slice(0 - 100ms), io_allowed = 100 + (-10) = 90, which means
only 90 ios can be dispatched without waiting;
5) assume that io is throttled in slice(0 - 100ms), and
throtl_trim_slice() update silce to (100ms - 200ms). In this case,
'carryover_ios/bytes' is not cleared and still only 90 ios can be
dispatched between 100ms - 200ms.
Fix this problem by updating 'carryover_ios/bytes' in
throtl_trim_slice().
Fixes: a880ae93e5b5 ("blk-throttle: fix io hung due to configuration updates")
Reported-by: zhuxiaohui <zhuxiaohui.400@bytedance.com>
Link: https://lore.kernel.org/all/20230812072116.42321-1-zhuxiaohui.400@bytedance.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-5-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:08 +08:00
|
|
|
time_elapsed) +
|
|
|
|
tg->carryover_bytes[rw];
|
|
|
|
io_trim = calculate_io_allowed(tg_iops_limit(tg, rw), time_elapsed) +
|
|
|
|
tg->carryover_ios[rw];
|
|
|
|
if (bytes_trim <= 0 && io_trim <= 0)
|
2010-09-16 05:06:35 +08:00
|
|
|
return;
|
|
|
|
|
blk-throttle: consider 'carryover_ios/bytes' in throtl_trim_slice()
Currently, 'carryover_ios/bytes' is not handled in throtl_trim_slice(),
for consequence, 'carryover_ios/bytes' will be used to throttle bio
multiple times, for example:
1) set iops limit to 100, and slice start is 0, slice end is 100ms;
2) current time is 0, and 10 ios are dispatched, those io won't be
throttled and io_disp is 10;
3) still at current time 0, update iops limit to 1000, carryover_ios is
updated to (0 - 10) = -10;
4) in this slice(0 - 100ms), io_allowed = 100 + (-10) = 90, which means
only 90 ios can be dispatched without waiting;
5) assume that io is throttled in slice(0 - 100ms), and
throtl_trim_slice() update silce to (100ms - 200ms). In this case,
'carryover_ios/bytes' is not cleared and still only 90 ios can be
dispatched between 100ms - 200ms.
Fix this problem by updating 'carryover_ios/bytes' in
throtl_trim_slice().
Fixes: a880ae93e5b5 ("blk-throttle: fix io hung due to configuration updates")
Reported-by: zhuxiaohui <zhuxiaohui.400@bytedance.com>
Link: https://lore.kernel.org/all/20230812072116.42321-1-zhuxiaohui.400@bytedance.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-5-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:08 +08:00
|
|
|
tg->carryover_bytes[rw] = 0;
|
|
|
|
if ((long long)tg->bytes_disp[rw] >= bytes_trim)
|
2010-09-16 05:06:35 +08:00
|
|
|
tg->bytes_disp[rw] -= bytes_trim;
|
|
|
|
else
|
|
|
|
tg->bytes_disp[rw] = 0;
|
|
|
|
|
blk-throttle: consider 'carryover_ios/bytes' in throtl_trim_slice()
Currently, 'carryover_ios/bytes' is not handled in throtl_trim_slice(),
for consequence, 'carryover_ios/bytes' will be used to throttle bio
multiple times, for example:
1) set iops limit to 100, and slice start is 0, slice end is 100ms;
2) current time is 0, and 10 ios are dispatched, those io won't be
throttled and io_disp is 10;
3) still at current time 0, update iops limit to 1000, carryover_ios is
updated to (0 - 10) = -10;
4) in this slice(0 - 100ms), io_allowed = 100 + (-10) = 90, which means
only 90 ios can be dispatched without waiting;
5) assume that io is throttled in slice(0 - 100ms), and
throtl_trim_slice() update silce to (100ms - 200ms). In this case,
'carryover_ios/bytes' is not cleared and still only 90 ios can be
dispatched between 100ms - 200ms.
Fix this problem by updating 'carryover_ios/bytes' in
throtl_trim_slice().
Fixes: a880ae93e5b5 ("blk-throttle: fix io hung due to configuration updates")
Reported-by: zhuxiaohui <zhuxiaohui.400@bytedance.com>
Link: https://lore.kernel.org/all/20230812072116.42321-1-zhuxiaohui.400@bytedance.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-5-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:08 +08:00
|
|
|
tg->carryover_ios[rw] = 0;
|
|
|
|
if ((int)tg->io_disp[rw] >= io_trim)
|
2010-09-16 05:06:37 +08:00
|
|
|
tg->io_disp[rw] -= io_trim;
|
|
|
|
else
|
|
|
|
tg->io_disp[rw] = 0;
|
|
|
|
|
2023-08-16 09:27:07 +08:00
|
|
|
tg->slice_start[rw] += time_elapsed;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_log(&tg->service_queue,
|
blk-throttle: consider 'carryover_ios/bytes' in throtl_trim_slice()
Currently, 'carryover_ios/bytes' is not handled in throtl_trim_slice(),
for consequence, 'carryover_ios/bytes' will be used to throttle bio
multiple times, for example:
1) set iops limit to 100, and slice start is 0, slice end is 100ms;
2) current time is 0, and 10 ios are dispatched, those io won't be
throttled and io_disp is 10;
3) still at current time 0, update iops limit to 1000, carryover_ios is
updated to (0 - 10) = -10;
4) in this slice(0 - 100ms), io_allowed = 100 + (-10) = 90, which means
only 90 ios can be dispatched without waiting;
5) assume that io is throttled in slice(0 - 100ms), and
throtl_trim_slice() update silce to (100ms - 200ms). In this case,
'carryover_ios/bytes' is not cleared and still only 90 ios can be
dispatched between 100ms - 200ms.
Fix this problem by updating 'carryover_ios/bytes' in
throtl_trim_slice().
Fixes: a880ae93e5b5 ("blk-throttle: fix io hung due to configuration updates")
Reported-by: zhuxiaohui <zhuxiaohui.400@bytedance.com>
Link: https://lore.kernel.org/all/20230812072116.42321-1-zhuxiaohui.400@bytedance.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-5-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:08 +08:00
|
|
|
"[%c] trim slice nr=%lu bytes=%lld io=%d start=%lu end=%lu jiffies=%lu",
|
2023-08-16 09:27:07 +08:00
|
|
|
rw == READ ? 'R' : 'W', time_elapsed / tg->td->throtl_slice,
|
|
|
|
bytes_trim, io_trim, tg->slice_start[rw], tg->slice_end[rw],
|
|
|
|
jiffies);
|
2022-08-29 10:22:39 +08:00
|
|
|
}
|
|
|
|
|
2022-08-29 10:22:40 +08:00
|
|
|
static void __tg_update_carryover(struct throtl_grp *tg, bool rw)
|
|
|
|
{
|
|
|
|
unsigned long jiffy_elapsed = jiffies - tg->slice_start[rw];
|
|
|
|
u64 bps_limit = tg_bps_limit(tg, rw);
|
|
|
|
u32 iops_limit = tg_iops_limit(tg, rw);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If config is updated while bios are still throttled, calculate and
|
|
|
|
* accumulate how many bytes/ios are waited across changes. And
|
|
|
|
* carryover_bytes/ios will be used to calculate new wait time under new
|
|
|
|
* configuration.
|
|
|
|
*/
|
|
|
|
if (bps_limit != U64_MAX)
|
|
|
|
tg->carryover_bytes[rw] +=
|
|
|
|
calculate_bytes_allowed(bps_limit, jiffy_elapsed) -
|
|
|
|
tg->bytes_disp[rw];
|
|
|
|
if (iops_limit != UINT_MAX)
|
|
|
|
tg->carryover_ios[rw] +=
|
|
|
|
calculate_io_allowed(iops_limit, jiffy_elapsed) -
|
|
|
|
tg->io_disp[rw];
|
|
|
|
}
|
|
|
|
|
|
|
|
static void tg_update_carryover(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
if (tg->service_queue.nr_queued[READ])
|
|
|
|
__tg_update_carryover(tg, READ);
|
|
|
|
if (tg->service_queue.nr_queued[WRITE])
|
|
|
|
__tg_update_carryover(tg, WRITE);
|
|
|
|
|
|
|
|
/* see comments in struct throtl_grp for meaning of these fields. */
|
2023-08-16 09:27:05 +08:00
|
|
|
throtl_log(&tg->service_queue, "%s: %lld %lld %d %d\n", __func__,
|
2022-08-29 10:22:40 +08:00
|
|
|
tg->carryover_bytes[READ], tg->carryover_bytes[WRITE],
|
|
|
|
tg->carryover_ios[READ], tg->carryover_ios[WRITE]);
|
|
|
|
}
|
|
|
|
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
static unsigned long tg_within_iops_limit(struct throtl_grp *tg, struct bio *bio,
|
|
|
|
u32 iops_limit)
|
2022-08-29 10:22:39 +08:00
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
blk-throttle: fix wrong comparation while 'carryover_ios/bytes' is negative
carryover_ios/bytes[] can be negative in the case that ios are
dispatched in the slice in advance, and then configuration is updated.
For example:
1) set iops limit to 1000, and slice start is 0, slice end is 100ms;
2) current time is 0, and 100 ios are dispatched, those ios will not be
throttled, hence io_disp is 100;
3) still at current time 0, update iops limit to 100, then carryover_ios
is (0 - 100) = -100;
4) then, dispatch a new io at time 0, the expected result is that this
io will wait for 1s. The calculation in tg_within_iops_limit:
io_disp = 0;
io_allowed = calculate_io_allowed + carryover_ios
= 10 + (-100) = -90;
io won't be throttled if (io_disp + 1 < io_allowed) passed.
Before this patch, in step 4) (io_disp + 1 < io_allowed) is passed,
because -90 for unsigned value is very huge, and such io won't be
throttled.
Fix this problem by checking if 'io/bytes_allowed' is negative first.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-3-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:06 +08:00
|
|
|
int io_allowed;
|
2022-08-29 10:22:39 +08:00
|
|
|
unsigned long jiffy_elapsed, jiffy_wait, jiffy_elapsed_rnd;
|
|
|
|
|
|
|
|
if (iops_limit == UINT_MAX) {
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
return 0;
|
2022-08-29 10:22:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
jiffy_elapsed = jiffies - tg->slice_start[rw];
|
|
|
|
|
|
|
|
/* Round up to the next throttle slice, wait time must be nonzero */
|
|
|
|
jiffy_elapsed_rnd = roundup(jiffy_elapsed + 1, tg->td->throtl_slice);
|
2022-08-29 10:22:40 +08:00
|
|
|
io_allowed = calculate_io_allowed(iops_limit, jiffy_elapsed_rnd) +
|
|
|
|
tg->carryover_ios[rw];
|
blk-throttle: fix wrong comparation while 'carryover_ios/bytes' is negative
carryover_ios/bytes[] can be negative in the case that ios are
dispatched in the slice in advance, and then configuration is updated.
For example:
1) set iops limit to 1000, and slice start is 0, slice end is 100ms;
2) current time is 0, and 100 ios are dispatched, those ios will not be
throttled, hence io_disp is 100;
3) still at current time 0, update iops limit to 100, then carryover_ios
is (0 - 100) = -100;
4) then, dispatch a new io at time 0, the expected result is that this
io will wait for 1s. The calculation in tg_within_iops_limit:
io_disp = 0;
io_allowed = calculate_io_allowed + carryover_ios
= 10 + (-100) = -90;
io won't be throttled if (io_disp + 1 < io_allowed) passed.
Before this patch, in step 4) (io_disp + 1 < io_allowed) is passed,
because -90 for unsigned value is very huge, and such io won't be
throttled.
Fix this problem by checking if 'io/bytes_allowed' is negative first.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-3-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:06 +08:00
|
|
|
if (io_allowed > 0 && tg->io_disp[rw] + 1 <= io_allowed)
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
return 0;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2010-09-16 05:06:37 +08:00
|
|
|
/* Calc approx time to dispatch */
|
Blk-throttle: reduce tail io latency when iops limit is enforced
When an application's iops has exceeded its cgroup's iops limit, surely it
is throttled and kernel will set a timer for dispatching, thus IO latency
includes the delay.
However, the dispatch delay which is calculated by the limit and the
elapsed jiffies is suboptimal. As the dispatch delay is only calculated
once the application's iops is (iops limit + 1), it doesn't need to wait
any longer than the remaining time of the current slice.
The difference can be proved by the following fio job and cgroup iops
setting,
-----
$ echo 4 > /mnt/config/nullb/disk1/mbps # limit nullb's bandwidth to 4MB/s for testing.
$ echo "253:1 riops=100 rbps=max" > /sys/fs/cgroup/unified/cg1/io.max
$ cat r2.job
[global]
name=fio-rand-read
filename=/dev/nullb1
rw=randread
bs=4k
direct=1
numjobs=1
time_based=1
runtime=60
group_reporting=1
[file1]
size=4G
ioengine=libaio
iodepth=1
rate_iops=50000
norandommap=1
thinktime=4ms
-----
wo patch:
file1: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.7-66-gedfc
Starting 1 process
read: IOPS=99, BW=400KiB/s (410kB/s)(23.4MiB/60001msec)
slat (usec): min=10, max=336, avg=27.71, stdev=17.82
clat (usec): min=2, max=28887, avg=5929.81, stdev=7374.29
lat (usec): min=24, max=28901, avg=5958.73, stdev=7366.22
clat percentiles (usec):
| 1.00th=[ 4], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 4],
| 30.00th=[ 4], 40.00th=[ 4], 50.00th=[ 6], 60.00th=[11731],
| 70.00th=[11863], 80.00th=[11994], 90.00th=[12911], 95.00th=[22676],
| 99.00th=[23725], 99.50th=[23987], 99.90th=[23987], 99.95th=[25035],
| 99.99th=[28967]
w/ patch:
file1: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.7-66-gedfc
Starting 1 process
read: IOPS=100, BW=400KiB/s (410kB/s)(23.4MiB/60005msec)
slat (usec): min=10, max=155, avg=23.24, stdev=16.79
clat (usec): min=2, max=12393, avg=5961.58, stdev=5959.25
lat (usec): min=23, max=12412, avg=5985.91, stdev=5951.92
clat percentiles (usec):
| 1.00th=[ 3], 5.00th=[ 3], 10.00th=[ 4], 20.00th=[ 4],
| 30.00th=[ 4], 40.00th=[ 5], 50.00th=[ 47], 60.00th=[11863],
| 70.00th=[11994], 80.00th=[11994], 90.00th=[11994], 95.00th=[11994],
| 99.00th=[11994], 99.50th=[11994], 99.90th=[12125], 99.95th=[12125],
| 99.99th=[12387]
Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-08-10 01:47:02 +08:00
|
|
|
jiffy_wait = jiffy_elapsed_rnd - jiffy_elapsed;
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
return jiffy_wait;
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
static unsigned long tg_within_bps_limit(struct throtl_grp *tg, struct bio *bio,
|
|
|
|
u64 bps_limit)
|
2010-09-16 05:06:37 +08:00
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
blk-throttle: fix wrong comparation while 'carryover_ios/bytes' is negative
carryover_ios/bytes[] can be negative in the case that ios are
dispatched in the slice in advance, and then configuration is updated.
For example:
1) set iops limit to 1000, and slice start is 0, slice end is 100ms;
2) current time is 0, and 100 ios are dispatched, those ios will not be
throttled, hence io_disp is 100;
3) still at current time 0, update iops limit to 100, then carryover_ios
is (0 - 100) = -100;
4) then, dispatch a new io at time 0, the expected result is that this
io will wait for 1s. The calculation in tg_within_iops_limit:
io_disp = 0;
io_allowed = calculate_io_allowed + carryover_ios
= 10 + (-100) = -90;
io won't be throttled if (io_disp + 1 < io_allowed) passed.
Before this patch, in step 4) (io_disp + 1 < io_allowed) is passed,
because -90 for unsigned value is very huge, and such io won't be
throttled.
Fix this problem by checking if 'io/bytes_allowed' is negative first.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-3-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:06 +08:00
|
|
|
long long bytes_allowed;
|
|
|
|
u64 extra_bytes;
|
2010-09-16 05:06:37 +08:00
|
|
|
unsigned long jiffy_elapsed, jiffy_wait, jiffy_elapsed_rnd;
|
2017-08-19 07:08:13 +08:00
|
|
|
unsigned int bio_size = throtl_bio_data_size(bio);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2022-02-16 12:45:12 +08:00
|
|
|
/* no need to throttle if this bio's bytes have been accounted */
|
blk-throttle: fix that io throttle can only work for single bio
Test scripts:
cd /sys/fs/cgroup/blkio/
echo "8:0 1024" > blkio.throttle.write_bps_device
echo $$ > cgroup.procs
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
Test result:
10240 bytes (10 kB, 10 KiB) copied, 10.0134 s, 1.0 kB/s
10240 bytes (10 kB, 10 KiB) copied, 10.0135 s, 1.0 kB/s
The problem is that the second bio is finished after 10s instead of 20s.
Root cause:
1) second bio will be flagged:
__blk_throtl_bio
while (true) {
...
if (sq->nr_queued[rw]) -> some bio is throttled already
break
};
bio_set_flag(bio, BIO_THROTTLED); -> flag the bio
2) flagged bio will be dispatched without waiting:
throtl_dispatch_tg
tg_may_dispatch
tg_with_in_bps_limit
if (bps_limit == U64_MAX || bio_flagged(bio, BIO_THROTTLED))
*wait = 0; -> wait time is zero
return true;
commit 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
support to count split bios for iops limit, thus it adds flagged bio
checking in tg_with_in_bps_limit() so that split bios will only count
once for bps limit, however, it introduce a new problem that io throttle
won't work if multiple bios are throttled.
In order to fix the problem, handle iops/bps limit in different ways:
1) for iops limit, there is no flag to record if the bio is throttled,
and iops is always applied.
2) for bps limit, original bio will be flagged with BIO_BPS_THROTTLED,
and io throttle will ignore bio with the flag.
Noted this patch also remove the code to set flag in __bio_clone(), it's
introduced in commit 111be8839817 ("block-throttle: avoid double
charge"), and author thinks split bio can be resubmited and throttled
again, which is wrong because split bio will continue to dispatch from
caller.
Fixes: 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20220829022240.3348319-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-29 10:22:37 +08:00
|
|
|
if (bps_limit == U64_MAX || bio_flagged(bio, BIO_BPS_THROTTLED)) {
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
return 0;
|
2020-09-07 16:10:17 +08:00
|
|
|
}
|
|
|
|
|
2010-09-16 05:06:35 +08:00
|
|
|
jiffy_elapsed = jiffy_elapsed_rnd = jiffies - tg->slice_start[rw];
|
|
|
|
|
|
|
|
/* Slice has just started. Consider one slice interval */
|
|
|
|
if (!jiffy_elapsed)
|
2017-03-28 01:51:37 +08:00
|
|
|
jiffy_elapsed_rnd = tg->td->throtl_slice;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
jiffy_elapsed_rnd = roundup(jiffy_elapsed_rnd, tg->td->throtl_slice);
|
2022-08-29 10:22:40 +08:00
|
|
|
bytes_allowed = calculate_bytes_allowed(bps_limit, jiffy_elapsed_rnd) +
|
|
|
|
tg->carryover_bytes[rw];
|
blk-throttle: fix wrong comparation while 'carryover_ios/bytes' is negative
carryover_ios/bytes[] can be negative in the case that ios are
dispatched in the slice in advance, and then configuration is updated.
For example:
1) set iops limit to 1000, and slice start is 0, slice end is 100ms;
2) current time is 0, and 100 ios are dispatched, those ios will not be
throttled, hence io_disp is 100;
3) still at current time 0, update iops limit to 100, then carryover_ios
is (0 - 100) = -100;
4) then, dispatch a new io at time 0, the expected result is that this
io will wait for 1s. The calculation in tg_within_iops_limit:
io_disp = 0;
io_allowed = calculate_io_allowed + carryover_ios
= 10 + (-100) = -90;
io won't be throttled if (io_disp + 1 < io_allowed) passed.
Before this patch, in step 4) (io_disp + 1 < io_allowed) is passed,
because -90 for unsigned value is very huge, and such io won't be
throttled.
Fix this problem by checking if 'io/bytes_allowed' is negative first.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230816012708.1193747-3-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-08-16 09:27:06 +08:00
|
|
|
if (bytes_allowed > 0 && tg->bytes_disp[rw] + bio_size <= bytes_allowed)
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
return 0;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
/* Calc approx time to dispatch */
|
2017-08-19 07:08:13 +08:00
|
|
|
extra_bytes = tg->bytes_disp[rw] + bio_size - bytes_allowed;
|
2020-09-07 16:10:16 +08:00
|
|
|
jiffy_wait = div64_u64(extra_bytes * HZ, bps_limit);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
if (!jiffy_wait)
|
|
|
|
jiffy_wait = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This wait time is without taking into consideration the rounding
|
|
|
|
* up we did. Add that time also.
|
|
|
|
*/
|
|
|
|
jiffy_wait = jiffy_wait + (jiffy_elapsed_rnd - jiffy_elapsed);
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
return jiffy_wait;
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns whether one can dispatch a bio or not. Also returns approx number
|
|
|
|
* of jiffies to wait before this bio is with-in IO rate and can be dispatched
|
|
|
|
*/
|
2013-05-15 04:52:32 +08:00
|
|
|
static bool tg_may_dispatch(struct throtl_grp *tg, struct bio *bio,
|
|
|
|
unsigned long *wait)
|
2010-09-16 05:06:37 +08:00
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
|
|
|
unsigned long bps_wait = 0, iops_wait = 0, max_wait = 0;
|
2020-09-07 16:10:16 +08:00
|
|
|
u64 bps_limit = tg_bps_limit(tg, rw);
|
|
|
|
u32 iops_limit = tg_iops_limit(tg, rw);
|
2010-09-16 05:06:37 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Currently whole state machine of group depends on first bio
|
|
|
|
* queued in the group bio list. So one should not be calling
|
|
|
|
* this function with a different bio if there are other bios
|
|
|
|
* queued.
|
|
|
|
*/
|
2013-05-15 04:52:35 +08:00
|
|
|
BUG_ON(tg->service_queue.nr_queued[rw] &&
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
bio != throtl_peek_queued(&tg->service_queue.queued[rw]));
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2010-09-16 05:06:37 +08:00
|
|
|
/* If tg->bps = -1, then BW is unlimited */
|
2022-03-18 21:01:44 +08:00
|
|
|
if ((bps_limit == U64_MAX && iops_limit == UINT_MAX) ||
|
|
|
|
tg->flags & THROTL_TG_CANCELING) {
|
2010-09-16 05:06:37 +08:00
|
|
|
if (wait)
|
|
|
|
*wait = 0;
|
2014-05-03 00:28:17 +08:00
|
|
|
return true;
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If previous slice expired, start a new one otherwise renew/extend
|
|
|
|
* existing slice to make sure it is at least throtl_slice interval
|
2016-09-20 05:12:41 +08:00
|
|
|
* long since now. New slice is started only for empty throttle group.
|
|
|
|
* If there is queued bio, that means there should be an active
|
|
|
|
* slice and it should be extended instead.
|
2010-09-16 05:06:37 +08:00
|
|
|
*/
|
2016-09-20 05:12:41 +08:00
|
|
|
if (throtl_slice_used(tg, rw) && !(tg->service_queue.nr_queued[rw]))
|
2022-08-29 10:22:40 +08:00
|
|
|
throtl_start_new_slice(tg, rw, true);
|
2010-09-16 05:06:37 +08:00
|
|
|
else {
|
2017-03-28 01:51:37 +08:00
|
|
|
if (time_before(tg->slice_end[rw],
|
|
|
|
jiffies + tg->td->throtl_slice))
|
|
|
|
throtl_extend_slice(tg, rw,
|
|
|
|
jiffies + tg->td->throtl_slice);
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: correct calculation of wait time in tg_may_dispatch
In C language, When executing "if (expression1 && expression2)" and
expression1 return false, the expression2 may not be executed.
For "tg_within_bps_limit(tg, bio, bps_limit, &bps_wait) &&
tg_within_iops_limit(tg, bio, iops_limit, &iops_wait))", if bps is
limited, tg_within_bps_limit will return false and
tg_within_iops_limit will not be called. So even bps and iops are
both limited, iops_wait will not be calculated and is always zero.
So wait time of iops is always ignored.
Fix this by always calling tg_within_bps_limit and tg_within_iops_limit
to get wait time for both bps and iops.
Observed that:
1. Wait time in tg_within_iops_limit/tg_within_bps_limit need always
be stored as wait argument is always passed.
2. wait time is stored to zero if iops/bps is limited otherwise non-zero
is stored.
Simpfy tg_within_iops_limit/tg_within_bps_limit by removing wait argument
and return wait time directly. Caller tg_may_dispatch checks if wait time
is zero to find if iops/bps is limited.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Link: https://lore.kernel.org/r/20221205115709.251489-5-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-05 19:57:04 +08:00
|
|
|
bps_wait = tg_within_bps_limit(tg, bio, bps_limit);
|
|
|
|
iops_wait = tg_within_iops_limit(tg, bio, iops_limit);
|
|
|
|
if (bps_wait + iops_wait == 0) {
|
2010-09-16 05:06:37 +08:00
|
|
|
if (wait)
|
|
|
|
*wait = 0;
|
2018-05-29 18:32:44 +08:00
|
|
|
return true;
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
max_wait = max(bps_wait, iops_wait);
|
|
|
|
|
|
|
|
if (wait)
|
|
|
|
*wait = max_wait;
|
|
|
|
|
|
|
|
if (time_before(tg->slice_end[rw], jiffies + max_wait))
|
2013-05-15 04:52:32 +08:00
|
|
|
throtl_extend_slice(tg, rw, jiffies + max_wait);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2018-05-29 18:32:44 +08:00
|
|
|
return false;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void throtl_charge_bio(struct throtl_grp *tg, struct bio *bio)
|
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
2017-08-19 07:08:13 +08:00
|
|
|
unsigned int bio_size = throtl_bio_data_size(bio);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
/* Charge the bio to the group */
|
blk-throttle: fix that io throttle can only work for single bio
Test scripts:
cd /sys/fs/cgroup/blkio/
echo "8:0 1024" > blkio.throttle.write_bps_device
echo $$ > cgroup.procs
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
Test result:
10240 bytes (10 kB, 10 KiB) copied, 10.0134 s, 1.0 kB/s
10240 bytes (10 kB, 10 KiB) copied, 10.0135 s, 1.0 kB/s
The problem is that the second bio is finished after 10s instead of 20s.
Root cause:
1) second bio will be flagged:
__blk_throtl_bio
while (true) {
...
if (sq->nr_queued[rw]) -> some bio is throttled already
break
};
bio_set_flag(bio, BIO_THROTTLED); -> flag the bio
2) flagged bio will be dispatched without waiting:
throtl_dispatch_tg
tg_may_dispatch
tg_with_in_bps_limit
if (bps_limit == U64_MAX || bio_flagged(bio, BIO_THROTTLED))
*wait = 0; -> wait time is zero
return true;
commit 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
support to count split bios for iops limit, thus it adds flagged bio
checking in tg_with_in_bps_limit() so that split bios will only count
once for bps limit, however, it introduce a new problem that io throttle
won't work if multiple bios are throttled.
In order to fix the problem, handle iops/bps limit in different ways:
1) for iops limit, there is no flag to record if the bio is throttled,
and iops is always applied.
2) for bps limit, original bio will be flagged with BIO_BPS_THROTTLED,
and io throttle will ignore bio with the flag.
Noted this patch also remove the code to set flag in __bio_clone(), it's
introduced in commit 111be8839817 ("block-throttle: avoid double
charge"), and author thinks split bio can be resubmited and throttled
again, which is wrong because split bio will continue to dispatch from
caller.
Fixes: 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20220829022240.3348319-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-29 10:22:37 +08:00
|
|
|
if (!bio_flagged(bio, BIO_BPS_THROTTLED)) {
|
2022-02-16 12:45:12 +08:00
|
|
|
tg->bytes_disp[rw] += bio_size;
|
|
|
|
tg->last_bytes_disp[rw] += bio_size;
|
|
|
|
}
|
|
|
|
|
2010-09-16 05:06:37 +08:00
|
|
|
tg->io_disp[rw]++;
|
2017-03-28 01:51:35 +08:00
|
|
|
tg->last_io_disp[rw]++;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
/**
|
|
|
|
* throtl_add_bio_tg - add a bio to the specified throtl_grp
|
|
|
|
* @bio: bio to add
|
|
|
|
* @qn: qnode to use
|
|
|
|
* @tg: the target throtl_grp
|
|
|
|
*
|
|
|
|
* Add @bio to @tg's service_queue using @qn. If @qn is not specified,
|
|
|
|
* tg->qnode_on_self[] is used.
|
|
|
|
*/
|
|
|
|
static void throtl_add_bio_tg(struct bio *bio, struct throtl_qnode *qn,
|
|
|
|
struct throtl_grp *tg)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2013-05-15 04:52:35 +08:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-16 05:06:35 +08:00
|
|
|
bool rw = bio_data_dir(bio);
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
if (!qn)
|
|
|
|
qn = &tg->qnode_on_self[rw];
|
|
|
|
|
2013-05-15 04:52:35 +08:00
|
|
|
/*
|
|
|
|
* If @tg doesn't currently have any bios queued in the same
|
|
|
|
* direction, queueing @bio can change when @tg should be
|
|
|
|
* dispatched. Mark that @tg was empty. This is automatically
|
2020-09-07 16:10:13 +08:00
|
|
|
* cleared on the next tg_update_disptime().
|
2013-05-15 04:52:35 +08:00
|
|
|
*/
|
|
|
|
if (!sq->nr_queued[rw])
|
|
|
|
tg->flags |= THROTL_TG_WAS_EMPTY;
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
throtl_qnode_add_bio(bio, qn, &sq->queued[rw]);
|
|
|
|
|
2013-05-15 04:52:35 +08:00
|
|
|
sq->nr_queued[rw]++;
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_enqueue_tg(tg);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
static void tg_update_disptime(struct throtl_grp *tg)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2013-05-15 04:52:35 +08:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-16 05:06:35 +08:00
|
|
|
unsigned long read_wait = -1, write_wait = -1, min_wait = -1, disptime;
|
|
|
|
struct bio *bio;
|
|
|
|
|
2017-01-22 05:15:33 +08:00
|
|
|
bio = throtl_peek_queued(&sq->queued[READ]);
|
|
|
|
if (bio)
|
2013-05-15 04:52:32 +08:00
|
|
|
tg_may_dispatch(tg, bio, &read_wait);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2017-01-22 05:15:33 +08:00
|
|
|
bio = throtl_peek_queued(&sq->queued[WRITE]);
|
|
|
|
if (bio)
|
2013-05-15 04:52:32 +08:00
|
|
|
tg_may_dispatch(tg, bio, &write_wait);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
min_wait = min(read_wait, write_wait);
|
|
|
|
disptime = jiffies + min_wait;
|
|
|
|
|
|
|
|
/* Update dispatch time */
|
2022-08-27 18:16:37 +08:00
|
|
|
throtl_rb_erase(&tg->rb_node, tg->service_queue.parent_sq);
|
2010-09-16 05:06:35 +08:00
|
|
|
tg->disptime = disptime;
|
2022-08-27 18:16:37 +08:00
|
|
|
tg_service_queue_add(tg);
|
2013-05-15 04:52:35 +08:00
|
|
|
|
|
|
|
/* see throtl_add_bio_tg() */
|
|
|
|
tg->flags &= ~THROTL_TG_WAS_EMPTY;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: Account for child group's start time in parent while bio climbs up
With the planned proper hierarchy support, a bio will climb up the
tree before actually being dispatched. This makes sure bio is also
subjected to parent's throttling limits, if any.
It might happen that parent is idle and when bio is transferred to
parent, a new slice starts fresh. But that is incorrect as parents
wait time should have started when bio was queued in child group and
causes IOs to be throttled more than configured as they climb the
hierarchy.
Given the fact that we have not written hierarchical algorithm in a
way where child's and parents time slices are synchronized, we
transfer the child's start time to parent if parent was idling. If
parent was busy doing dispatch of other bios all this while, this is
not an issue.
Child's slice start time is passed to parent. Parent looks at its
last expired slice start time. If child's start time is after parents
old start time, that means parent had been idle and after parent
went idle, child had an IO queued. So use child's start time as
parent start time.
If parent's start time is after child's start time, that means,
when IO got queued in child group, parent was not idle. But later
it dispatched some IO, its slice got trimmed and then it went idle.
After a while child's request got shifted in parent group. In this
case use parent's old start time as new start time as that's the
duration of slice we did not use.
This logic is far from perfect as if there are multiple childs
then first child transferring the bio decides the start time while
a bio might have queued up even earlier in other child, which is
yet to be transferred up to parent. In that case we will lose
time and bandwidth in parent. This patch is just an approximation
to make situation somewhat better.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-05-15 04:52:38 +08:00
|
|
|
static void start_parent_slice_with_credit(struct throtl_grp *child_tg,
|
|
|
|
struct throtl_grp *parent_tg, bool rw)
|
|
|
|
{
|
|
|
|
if (throtl_slice_used(parent_tg, rw)) {
|
|
|
|
throtl_start_new_slice_with_credit(parent_tg, rw,
|
|
|
|
child_tg->slice_start[rw]);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
static void tg_dispatch_one_bio(struct throtl_grp *tg, bool rw)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2013-05-15 04:52:35 +08:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2013-05-15 04:52:38 +08:00
|
|
|
struct throtl_service_queue *parent_sq = sq->parent_sq;
|
|
|
|
struct throtl_grp *parent_tg = sq_to_tg(parent_sq);
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
struct throtl_grp *tg_to_put = NULL;
|
2010-09-16 05:06:35 +08:00
|
|
|
struct bio *bio;
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
/*
|
|
|
|
* @bio is being transferred from @tg to @parent_sq. Popping a bio
|
|
|
|
* from @tg may put its reference and @parent_sq might end up
|
|
|
|
* getting released prematurely. Remember the tg to put and put it
|
|
|
|
* after @bio is transferred to @parent_sq.
|
|
|
|
*/
|
|
|
|
bio = throtl_pop_queued(&sq->queued[rw], &tg_to_put);
|
2013-05-15 04:52:35 +08:00
|
|
|
sq->nr_queued[rw]--;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
throtl_charge_bio(tg, bio);
|
2013-05-15 04:52:38 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If our parent is another tg, we just need to transfer @bio to
|
|
|
|
* the parent using throtl_add_bio_tg(). If our parent is
|
|
|
|
* @td->service_queue, @bio is ready to be issued. Put it on its
|
|
|
|
* bio_lists[] and decrease total number queued. The caller is
|
|
|
|
* responsible for issuing these bios.
|
|
|
|
*/
|
|
|
|
if (parent_tg) {
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
throtl_add_bio_tg(bio, &tg->qnode_on_parent[rw], parent_tg);
|
blk-throttle: Account for child group's start time in parent while bio climbs up
With the planned proper hierarchy support, a bio will climb up the
tree before actually being dispatched. This makes sure bio is also
subjected to parent's throttling limits, if any.
It might happen that parent is idle and when bio is transferred to
parent, a new slice starts fresh. But that is incorrect as parents
wait time should have started when bio was queued in child group and
causes IOs to be throttled more than configured as they climb the
hierarchy.
Given the fact that we have not written hierarchical algorithm in a
way where child's and parents time slices are synchronized, we
transfer the child's start time to parent if parent was idling. If
parent was busy doing dispatch of other bios all this while, this is
not an issue.
Child's slice start time is passed to parent. Parent looks at its
last expired slice start time. If child's start time is after parents
old start time, that means parent had been idle and after parent
went idle, child had an IO queued. So use child's start time as
parent start time.
If parent's start time is after child's start time, that means,
when IO got queued in child group, parent was not idle. But later
it dispatched some IO, its slice got trimmed and then it went idle.
After a while child's request got shifted in parent group. In this
case use parent's old start time as new start time as that's the
duration of slice we did not use.
This logic is far from perfect as if there are multiple childs
then first child transferring the bio decides the start time while
a bio might have queued up even earlier in other child, which is
yet to be transferred up to parent. In that case we will lose
time and bandwidth in parent. This patch is just an approximation
to make situation somewhat better.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-05-15 04:52:38 +08:00
|
|
|
start_parent_slice_with_credit(tg, parent_tg, rw);
|
2013-05-15 04:52:38 +08:00
|
|
|
} else {
|
2022-12-05 19:57:02 +08:00
|
|
|
bio_set_flag(bio, BIO_BPS_THROTTLED);
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
throtl_qnode_add_bio(bio, &tg->qnode_on_parent[rw],
|
|
|
|
&parent_sq->queued[rw]);
|
2013-05-15 04:52:38 +08:00
|
|
|
BUG_ON(tg->td->nr_queued[rw] <= 0);
|
|
|
|
tg->td->nr_queued[rw]--;
|
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:32 +08:00
|
|
|
throtl_trim_slice(tg, rw);
|
2013-05-15 04:52:38 +08:00
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
if (tg_to_put)
|
|
|
|
blkg_put(tg_to_blkg(tg_to_put));
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
static int throtl_dispatch_tg(struct throtl_grp *tg)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2013-05-15 04:52:35 +08:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-16 05:06:35 +08:00
|
|
|
unsigned int nr_reads = 0, nr_writes = 0;
|
2020-09-07 16:10:15 +08:00
|
|
|
unsigned int max_nr_reads = THROTL_GRP_QUANTUM * 3 / 4;
|
|
|
|
unsigned int max_nr_writes = THROTL_GRP_QUANTUM - max_nr_reads;
|
2010-09-16 05:06:35 +08:00
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
/* Try to dispatch 75% READS and 25% WRITES */
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
while ((bio = throtl_peek_queued(&sq->queued[READ])) &&
|
2013-05-15 04:52:32 +08:00
|
|
|
tg_may_dispatch(tg, bio, NULL)) {
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
tg_dispatch_one_bio(tg, bio_data_dir(bio));
|
2010-09-16 05:06:35 +08:00
|
|
|
nr_reads++;
|
|
|
|
|
|
|
|
if (nr_reads >= max_nr_reads)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
while ((bio = throtl_peek_queued(&sq->queued[WRITE])) &&
|
2013-05-15 04:52:32 +08:00
|
|
|
tg_may_dispatch(tg, bio, NULL)) {
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
tg_dispatch_one_bio(tg, bio_data_dir(bio));
|
2010-09-16 05:06:35 +08:00
|
|
|
nr_writes++;
|
|
|
|
|
|
|
|
if (nr_writes >= max_nr_writes)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return nr_reads + nr_writes;
|
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:35 +08:00
|
|
|
static int throtl_select_dispatch(struct throtl_service_queue *parent_sq)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
|
|
|
unsigned int nr_disp = 0;
|
|
|
|
|
|
|
|
while (1) {
|
2020-10-08 11:52:27 +08:00
|
|
|
struct throtl_grp *tg;
|
2018-05-29 16:29:12 +08:00
|
|
|
struct throtl_service_queue *sq;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2020-10-08 11:52:27 +08:00
|
|
|
if (!parent_sq->nr_pending)
|
|
|
|
break;
|
|
|
|
|
|
|
|
tg = throtl_rb_first(parent_sq);
|
2010-09-16 05:06:35 +08:00
|
|
|
if (!tg)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (time_before(jiffies, tg->disptime))
|
|
|
|
break;
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
nr_disp += throtl_dispatch_tg(tg);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2018-05-29 16:29:12 +08:00
|
|
|
sq = &tg->service_queue;
|
2022-08-27 18:16:35 +08:00
|
|
|
if (sq->nr_queued[READ] || sq->nr_queued[WRITE])
|
2013-05-15 04:52:36 +08:00
|
|
|
tg_update_disptime(tg);
|
2022-08-27 18:16:36 +08:00
|
|
|
else
|
|
|
|
throtl_dequeue_tg(tg);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2020-09-07 16:10:15 +08:00
|
|
|
if (nr_disp >= THROTL_QUANTUM)
|
2010-09-16 05:06:35 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return nr_disp;
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
static bool throtl_can_upgrade(struct throtl_data *td,
|
|
|
|
struct throtl_grp *this_tg);
|
2013-05-15 04:52:37 +08:00
|
|
|
/**
|
|
|
|
* throtl_pending_timer_fn - timer function for service_queue->pending_timer
|
2019-05-31 08:00:48 +08:00
|
|
|
* @t: the pending_timer member of the throtl_service_queue being serviced
|
2013-05-15 04:52:37 +08:00
|
|
|
*
|
|
|
|
* This timer is armed when a child throtl_grp with active bio's become
|
|
|
|
* pending and queued on the service_queue's pending_tree and expires when
|
|
|
|
* the first child throtl_grp should be dispatched. This function
|
2013-05-15 04:52:38 +08:00
|
|
|
* dispatches bio's from the children throtl_grps to the parent
|
|
|
|
* service_queue.
|
|
|
|
*
|
|
|
|
* If the parent's parent is another throtl_grp, dispatching is propagated
|
|
|
|
* by either arming its pending_timer or repeating dispatch directly. If
|
|
|
|
* the top-level service_tree is reached, throtl_data->dispatch_work is
|
|
|
|
* kicked so that the ready bio's are issued.
|
2013-05-15 04:52:37 +08:00
|
|
|
*/
|
treewide: setup_timer() -> timer_setup()
This converts all remaining cases of the old setup_timer() API into using
timer_setup(), where the callback argument is the structure already
holding the struct timer_list. These should have no behavioral changes,
since they just change which pointer is passed into the callback with
the same available pointers after conversion. It handles the following
examples, in addition to some other variations.
Casting from unsigned long:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
setup_timer(&ptr->my_timer, my_callback, ptr);
and forced object casts:
void my_callback(struct something *ptr)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, (unsigned long)ptr);
become:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
Direct function assignments:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
ptr->my_timer.function = my_callback;
have a temporary cast added, along with converting the args:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
ptr->my_timer.function = (TIMER_FUNC_TYPE)my_callback;
And finally, callbacks without a data assignment:
void my_callback(unsigned long data)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, 0);
have their argument renamed to verify they're unused during conversion:
void my_callback(struct timer_list *unused)
{
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
The conversion is done with the following Coccinelle script:
spatch --very-quiet --all-includes --include-headers \
-I ./arch/x86/include -I ./arch/x86/include/generated \
-I ./include -I ./arch/x86/include/uapi \
-I ./arch/x86/include/generated/uapi -I ./include/uapi \
-I ./include/generated/uapi --include ./include/linux/kconfig.h \
--dir . \
--cocci-file ~/src/data/timer_setup.cocci
@fix_address_of@
expression e;
@@
setup_timer(
-&(e)
+&e
, ...)
// Update any raw setup_timer() usages that have a NULL callback, but
// would otherwise match change_timer_function_usage, since the latter
// will update all function assignments done in the face of a NULL
// function initialization in setup_timer().
@change_timer_function_usage_NULL@
expression _E;
identifier _timer;
type _cast_data;
@@
(
-setup_timer(&_E->_timer, NULL, _E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E->_timer, NULL, (_cast_data)_E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, &_E);
+timer_setup(&_E._timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, (_cast_data)&_E);
+timer_setup(&_E._timer, NULL, 0);
)
@change_timer_function_usage@
expression _E;
identifier _timer;
struct timer_list _stl;
identifier _callback;
type _cast_func, _cast_data;
@@
(
-setup_timer(&_E->_timer, _callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
_E->_timer@_stl.function = _callback;
|
_E->_timer@_stl.function = &_callback;
|
_E->_timer@_stl.function = (_cast_func)_callback;
|
_E->_timer@_stl.function = (_cast_func)&_callback;
|
_E._timer@_stl.function = _callback;
|
_E._timer@_stl.function = &_callback;
|
_E._timer@_stl.function = (_cast_func)_callback;
|
_E._timer@_stl.function = (_cast_func)&_callback;
)
// callback(unsigned long arg)
@change_callback_handle_cast
depends on change_timer_function_usage@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
identifier _handle;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
(
... when != _origarg
_handletype *_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
)
}
// callback(unsigned long arg) without existing variable
@change_callback_handle_cast_no_arg
depends on change_timer_function_usage &&
!change_callback_handle_cast@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
+ _handletype *_origarg = from_timer(_origarg, t, _timer);
+
... when != _origarg
- (_handletype *)_origarg
+ _origarg
... when != _origarg
}
// Avoid already converted callbacks.
@match_callback_converted
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier t;
@@
void _callback(struct timer_list *t)
{ ... }
// callback(struct something *handle)
@change_callback_handle_arg
depends on change_timer_function_usage &&
!match_callback_converted &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
@@
void _callback(
-_handletype *_handle
+struct timer_list *t
)
{
+ _handletype *_handle = from_timer(_handle, t, _timer);
...
}
// If change_callback_handle_arg ran on an empty function, remove
// the added handler.
@unchange_callback_handle_arg
depends on change_timer_function_usage &&
change_callback_handle_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
identifier t;
@@
void _callback(struct timer_list *t)
{
- _handletype *_handle = from_timer(_handle, t, _timer);
}
// We only want to refactor the setup_timer() data argument if we've found
// the matching callback. This undoes changes in change_timer_function_usage.
@unchange_timer_function_usage
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg &&
!change_callback_handle_arg@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type change_timer_function_usage._cast_data;
@@
(
-timer_setup(&_E->_timer, _callback, 0);
+setup_timer(&_E->_timer, _callback, (_cast_data)_E);
|
-timer_setup(&_E._timer, _callback, 0);
+setup_timer(&_E._timer, _callback, (_cast_data)&_E);
)
// If we fixed a callback from a .function assignment, fix the
// assignment cast now.
@change_timer_function_assignment
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_func;
typedef TIMER_FUNC_TYPE;
@@
(
_E->_timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-&_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
)
// Sometimes timer functions are called directly. Replace matched args.
@change_timer_function_calls
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression _E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_data;
@@
_callback(
(
-(_cast_data)_E
+&_E->_timer
|
-(_cast_data)&_E
+&_E._timer
|
-_E
+&_E->_timer
)
)
// If a timer has been configured without a data argument, it can be
// converted without regard to the callback argument, since it is unused.
@match_timer_function_unused_data@
expression _E;
identifier _timer;
identifier _callback;
@@
(
-setup_timer(&_E->_timer, _callback, 0);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0L);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0UL);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0L);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0UL);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0L);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0UL);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0L);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0UL);
+timer_setup(_timer, _callback, 0);
)
@change_callback_unused_data
depends on match_timer_function_unused_data@
identifier match_timer_function_unused_data._callback;
type _origtype;
identifier _origarg;
@@
void _callback(
-_origtype _origarg
+struct timer_list *unused
)
{
... when != _origarg
}
Signed-off-by: Kees Cook <keescook@chromium.org>
2017-10-17 05:43:17 +08:00
|
|
|
static void throtl_pending_timer_fn(struct timer_list *t)
|
2013-05-15 04:52:36 +08:00
|
|
|
{
|
treewide: setup_timer() -> timer_setup()
This converts all remaining cases of the old setup_timer() API into using
timer_setup(), where the callback argument is the structure already
holding the struct timer_list. These should have no behavioral changes,
since they just change which pointer is passed into the callback with
the same available pointers after conversion. It handles the following
examples, in addition to some other variations.
Casting from unsigned long:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
setup_timer(&ptr->my_timer, my_callback, ptr);
and forced object casts:
void my_callback(struct something *ptr)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, (unsigned long)ptr);
become:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
Direct function assignments:
void my_callback(unsigned long data)
{
struct something *ptr = (struct something *)data;
...
}
...
ptr->my_timer.function = my_callback;
have a temporary cast added, along with converting the args:
void my_callback(struct timer_list *t)
{
struct something *ptr = from_timer(ptr, t, my_timer);
...
}
...
ptr->my_timer.function = (TIMER_FUNC_TYPE)my_callback;
And finally, callbacks without a data assignment:
void my_callback(unsigned long data)
{
...
}
...
setup_timer(&ptr->my_timer, my_callback, 0);
have their argument renamed to verify they're unused during conversion:
void my_callback(struct timer_list *unused)
{
...
}
...
timer_setup(&ptr->my_timer, my_callback, 0);
The conversion is done with the following Coccinelle script:
spatch --very-quiet --all-includes --include-headers \
-I ./arch/x86/include -I ./arch/x86/include/generated \
-I ./include -I ./arch/x86/include/uapi \
-I ./arch/x86/include/generated/uapi -I ./include/uapi \
-I ./include/generated/uapi --include ./include/linux/kconfig.h \
--dir . \
--cocci-file ~/src/data/timer_setup.cocci
@fix_address_of@
expression e;
@@
setup_timer(
-&(e)
+&e
, ...)
// Update any raw setup_timer() usages that have a NULL callback, but
// would otherwise match change_timer_function_usage, since the latter
// will update all function assignments done in the face of a NULL
// function initialization in setup_timer().
@change_timer_function_usage_NULL@
expression _E;
identifier _timer;
type _cast_data;
@@
(
-setup_timer(&_E->_timer, NULL, _E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E->_timer, NULL, (_cast_data)_E);
+timer_setup(&_E->_timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, &_E);
+timer_setup(&_E._timer, NULL, 0);
|
-setup_timer(&_E._timer, NULL, (_cast_data)&_E);
+timer_setup(&_E._timer, NULL, 0);
)
@change_timer_function_usage@
expression _E;
identifier _timer;
struct timer_list _stl;
identifier _callback;
type _cast_func, _cast_data;
@@
(
-setup_timer(&_E->_timer, _callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, &_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, _E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, &_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)_E);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, (_cast_func)&_callback, (_cast_data)&_E);
+timer_setup(&_E._timer, _callback, 0);
|
_E->_timer@_stl.function = _callback;
|
_E->_timer@_stl.function = &_callback;
|
_E->_timer@_stl.function = (_cast_func)_callback;
|
_E->_timer@_stl.function = (_cast_func)&_callback;
|
_E._timer@_stl.function = _callback;
|
_E._timer@_stl.function = &_callback;
|
_E._timer@_stl.function = (_cast_func)_callback;
|
_E._timer@_stl.function = (_cast_func)&_callback;
)
// callback(unsigned long arg)
@change_callback_handle_cast
depends on change_timer_function_usage@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
identifier _handle;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
(
... when != _origarg
_handletype *_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(_handletype *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
|
... when != _origarg
_handletype *_handle;
... when != _handle
_handle =
-(void *)_origarg;
+from_timer(_handle, t, _timer);
... when != _origarg
)
}
// callback(unsigned long arg) without existing variable
@change_callback_handle_cast_no_arg
depends on change_timer_function_usage &&
!change_callback_handle_cast@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _origtype;
identifier _origarg;
type _handletype;
@@
void _callback(
-_origtype _origarg
+struct timer_list *t
)
{
+ _handletype *_origarg = from_timer(_origarg, t, _timer);
+
... when != _origarg
- (_handletype *)_origarg
+ _origarg
... when != _origarg
}
// Avoid already converted callbacks.
@match_callback_converted
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier t;
@@
void _callback(struct timer_list *t)
{ ... }
// callback(struct something *handle)
@change_callback_handle_arg
depends on change_timer_function_usage &&
!match_callback_converted &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
@@
void _callback(
-_handletype *_handle
+struct timer_list *t
)
{
+ _handletype *_handle = from_timer(_handle, t, _timer);
...
}
// If change_callback_handle_arg ran on an empty function, remove
// the added handler.
@unchange_callback_handle_arg
depends on change_timer_function_usage &&
change_callback_handle_arg@
identifier change_timer_function_usage._callback;
identifier change_timer_function_usage._timer;
type _handletype;
identifier _handle;
identifier t;
@@
void _callback(struct timer_list *t)
{
- _handletype *_handle = from_timer(_handle, t, _timer);
}
// We only want to refactor the setup_timer() data argument if we've found
// the matching callback. This undoes changes in change_timer_function_usage.
@unchange_timer_function_usage
depends on change_timer_function_usage &&
!change_callback_handle_cast &&
!change_callback_handle_cast_no_arg &&
!change_callback_handle_arg@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type change_timer_function_usage._cast_data;
@@
(
-timer_setup(&_E->_timer, _callback, 0);
+setup_timer(&_E->_timer, _callback, (_cast_data)_E);
|
-timer_setup(&_E._timer, _callback, 0);
+setup_timer(&_E._timer, _callback, (_cast_data)&_E);
)
// If we fixed a callback from a .function assignment, fix the
// assignment cast now.
@change_timer_function_assignment
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression change_timer_function_usage._E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_func;
typedef TIMER_FUNC_TYPE;
@@
(
_E->_timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E->_timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-&_callback;
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)_callback
+(TIMER_FUNC_TYPE)_callback
;
|
_E._timer.function =
-(_cast_func)&_callback
+(TIMER_FUNC_TYPE)_callback
;
)
// Sometimes timer functions are called directly. Replace matched args.
@change_timer_function_calls
depends on change_timer_function_usage &&
(change_callback_handle_cast ||
change_callback_handle_cast_no_arg ||
change_callback_handle_arg)@
expression _E;
identifier change_timer_function_usage._timer;
identifier change_timer_function_usage._callback;
type _cast_data;
@@
_callback(
(
-(_cast_data)_E
+&_E->_timer
|
-(_cast_data)&_E
+&_E._timer
|
-_E
+&_E->_timer
)
)
// If a timer has been configured without a data argument, it can be
// converted without regard to the callback argument, since it is unused.
@match_timer_function_unused_data@
expression _E;
identifier _timer;
identifier _callback;
@@
(
-setup_timer(&_E->_timer, _callback, 0);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0L);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E->_timer, _callback, 0UL);
+timer_setup(&_E->_timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0L);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_E._timer, _callback, 0UL);
+timer_setup(&_E._timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0L);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(&_timer, _callback, 0UL);
+timer_setup(&_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0L);
+timer_setup(_timer, _callback, 0);
|
-setup_timer(_timer, _callback, 0UL);
+timer_setup(_timer, _callback, 0);
)
@change_callback_unused_data
depends on match_timer_function_unused_data@
identifier match_timer_function_unused_data._callback;
type _origtype;
identifier _origarg;
@@
void _callback(
-_origtype _origarg
+struct timer_list *unused
)
{
... when != _origarg
}
Signed-off-by: Kees Cook <keescook@chromium.org>
2017-10-17 05:43:17 +08:00
|
|
|
struct throtl_service_queue *sq = from_timer(sq, t, pending_timer);
|
2013-05-15 04:52:38 +08:00
|
|
|
struct throtl_grp *tg = sq_to_tg(sq);
|
2013-05-15 04:52:36 +08:00
|
|
|
struct throtl_data *td = sq_to_td(sq);
|
2013-05-15 04:52:38 +08:00
|
|
|
struct throtl_service_queue *parent_sq;
|
2022-03-18 21:01:42 +08:00
|
|
|
struct request_queue *q;
|
2013-05-15 04:52:38 +08:00
|
|
|
bool dispatched;
|
2013-05-15 04:52:37 +08:00
|
|
|
int ret;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2022-03-18 21:01:42 +08:00
|
|
|
/* throtl_data may be gone, so figure out request queue by blkg */
|
|
|
|
if (tg)
|
2023-02-15 02:33:08 +08:00
|
|
|
q = tg->pd.blkg->q;
|
2022-03-18 21:01:42 +08:00
|
|
|
else
|
|
|
|
q = td->queue;
|
|
|
|
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_lock_irq(&q->queue_lock);
|
2022-03-18 21:01:42 +08:00
|
|
|
|
2023-02-15 02:33:04 +08:00
|
|
|
if (!q->root_blkg)
|
2022-03-18 21:01:42 +08:00
|
|
|
goto out_unlock;
|
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
if (throtl_can_upgrade(td, NULL))
|
|
|
|
throtl_upgrade_state(td);
|
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
again:
|
|
|
|
parent_sq = sq->parent_sq;
|
|
|
|
dispatched = false;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
while (true) {
|
|
|
|
throtl_log(sq, "dispatch nr_queued=%u read=%u write=%u",
|
2013-05-15 04:52:38 +08:00
|
|
|
sq->nr_queued[READ] + sq->nr_queued[WRITE],
|
|
|
|
sq->nr_queued[READ], sq->nr_queued[WRITE]);
|
2013-05-15 04:52:37 +08:00
|
|
|
|
|
|
|
ret = throtl_select_dispatch(sq);
|
|
|
|
if (ret) {
|
|
|
|
throtl_log(sq, "bios disp=%u", ret);
|
|
|
|
dispatched = true;
|
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
if (throtl_schedule_next_dispatch(sq, false))
|
|
|
|
break;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
/* this dispatch windows is still open, relax and repeat */
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_unlock_irq(&q->queue_lock);
|
2013-05-15 04:52:37 +08:00
|
|
|
cpu_relax();
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_lock_irq(&q->queue_lock);
|
2013-05-15 04:52:35 +08:00
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
if (!dispatched)
|
|
|
|
goto out_unlock;
|
2013-05-15 04:52:37 +08:00
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
if (parent_sq) {
|
|
|
|
/* @parent_sq is another throl_grp, propagate dispatch */
|
|
|
|
if (tg->flags & THROTL_TG_WAS_EMPTY) {
|
|
|
|
tg_update_disptime(tg);
|
|
|
|
if (!throtl_schedule_next_dispatch(parent_sq, false)) {
|
|
|
|
/* window is already open, repeat dispatching */
|
|
|
|
sq = parent_sq;
|
|
|
|
tg = sq_to_tg(sq);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
2020-09-07 16:10:13 +08:00
|
|
|
/* reached the top-level, queue issuing */
|
2013-05-15 04:52:38 +08:00
|
|
|
queue_work(kthrotld_workqueue, &td->dispatch_work);
|
|
|
|
}
|
|
|
|
out_unlock:
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_unlock_irq(&q->queue_lock);
|
2013-05-15 04:52:37 +08:00
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
/**
|
|
|
|
* blk_throtl_dispatch_work_fn - work function for throtl_data->dispatch_work
|
|
|
|
* @work: work item being executed
|
|
|
|
*
|
2020-09-07 16:10:13 +08:00
|
|
|
* This function is queued for execution when bios reach the bio_lists[]
|
|
|
|
* of throtl_data->service_queue. Those bios are ready and issued by this
|
2013-05-15 04:52:37 +08:00
|
|
|
* function.
|
|
|
|
*/
|
2014-04-18 03:41:16 +08:00
|
|
|
static void blk_throtl_dispatch_work_fn(struct work_struct *work)
|
2013-05-15 04:52:37 +08:00
|
|
|
{
|
|
|
|
struct throtl_data *td = container_of(work, struct throtl_data,
|
|
|
|
dispatch_work);
|
|
|
|
struct throtl_service_queue *td_sq = &td->service_queue;
|
|
|
|
struct request_queue *q = td->queue;
|
|
|
|
struct bio_list bio_list_on_stack;
|
|
|
|
struct bio *bio;
|
|
|
|
struct blk_plug plug;
|
|
|
|
int rw;
|
|
|
|
|
|
|
|
bio_list_init(&bio_list_on_stack);
|
|
|
|
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_lock_irq(&q->queue_lock);
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
for (rw = READ; rw <= WRITE; rw++)
|
|
|
|
while ((bio = throtl_pop_queued(&td_sq->queued[rw], NULL)))
|
|
|
|
bio_list_add(&bio_list_on_stack, bio);
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_unlock_irq(&q->queue_lock);
|
2013-05-15 04:52:37 +08:00
|
|
|
|
|
|
|
if (!bio_list_empty(&bio_list_on_stack)) {
|
2011-03-09 15:27:37 +08:00
|
|
|
blk_start_plug(&plug);
|
2020-07-01 16:59:44 +08:00
|
|
|
while ((bio = bio_list_pop(&bio_list_on_stack)))
|
2022-02-16 12:45:10 +08:00
|
|
|
submit_bio_noacct_nocheck(bio);
|
2011-03-09 15:27:37 +08:00
|
|
|
blk_finish_plug(&plug);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-17 04:57:26 +08:00
|
|
|
static u64 tg_prfill_conf_u64(struct seq_file *sf, struct blkg_policy_data *pd,
|
|
|
|
int off)
|
2012-04-02 05:38:43 +08:00
|
|
|
{
|
2012-04-17 04:57:26 +08:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
u64 v = *(u64 *)((void *)tg + off);
|
2012-04-02 05:38:43 +08:00
|
|
|
|
2017-03-28 01:51:29 +08:00
|
|
|
if (v == U64_MAX)
|
2012-04-02 05:38:43 +08:00
|
|
|
return 0;
|
2012-04-17 04:57:26 +08:00
|
|
|
return __blkg_prfill_u64(sf, pd, v);
|
2012-04-02 05:38:43 +08:00
|
|
|
}
|
|
|
|
|
2012-04-17 04:57:26 +08:00
|
|
|
static u64 tg_prfill_conf_uint(struct seq_file *sf, struct blkg_policy_data *pd,
|
|
|
|
int off)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2012-04-17 04:57:26 +08:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
unsigned int v = *(unsigned int *)((void *)tg + off);
|
2010-10-01 20:49:49 +08:00
|
|
|
|
2017-03-28 01:51:29 +08:00
|
|
|
if (v == UINT_MAX)
|
2012-04-02 05:38:44 +08:00
|
|
|
return 0;
|
2012-04-17 04:57:26 +08:00
|
|
|
return __blkg_prfill_u64(sf, pd, v);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-12-06 01:28:04 +08:00
|
|
|
static int tg_print_conf_u64(struct seq_file *sf, void *v)
|
2010-09-16 05:06:37 +08:00
|
|
|
{
|
2013-12-06 01:28:04 +08:00
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), tg_prfill_conf_u64,
|
|
|
|
&blkcg_policy_throtl, seq_cft(sf)->private, false);
|
2012-04-02 05:38:44 +08:00
|
|
|
return 0;
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
2013-12-06 01:28:04 +08:00
|
|
|
static int tg_print_conf_uint(struct seq_file *sf, void *v)
|
2010-09-16 05:06:37 +08:00
|
|
|
{
|
2013-12-06 01:28:04 +08:00
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), tg_prfill_conf_uint,
|
|
|
|
&blkcg_policy_throtl, seq_cft(sf)->private, false);
|
2012-04-02 05:38:44 +08:00
|
|
|
return 0;
|
2012-04-02 05:38:43 +08:00
|
|
|
}
|
|
|
|
|
2017-05-18 04:07:26 +08:00
|
|
|
static void tg_conf_updated(struct throtl_grp *tg, bool global)
|
2012-04-02 05:38:43 +08:00
|
|
|
{
|
2015-08-19 05:55:32 +08:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2013-08-09 08:11:25 +08:00
|
|
|
struct cgroup_subsys_state *pos_css;
|
2015-08-19 05:55:32 +08:00
|
|
|
struct blkcg_gq *blkg;
|
2012-04-02 05:38:44 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"limit change rbps=%llu wbps=%llu riops=%u wiops=%u",
|
2017-03-28 01:51:30 +08:00
|
|
|
tg_bps_limit(tg, READ), tg_bps_limit(tg, WRITE),
|
|
|
|
tg_iops_limit(tg, READ), tg_iops_limit(tg, WRITE));
|
2013-05-15 04:52:31 +08:00
|
|
|
|
2023-11-17 10:35:22 +08:00
|
|
|
rcu_read_lock();
|
2013-05-15 04:52:38 +08:00
|
|
|
/*
|
|
|
|
* Update has_rules[] flags for the updated tg's subtree. A tg is
|
|
|
|
* considered to have rules if either the tg itself or any of its
|
|
|
|
* ancestors has rules. This identifies groups without any
|
|
|
|
* restrictions in the whole hierarchy and allows them to bypass
|
|
|
|
* blk-throttle.
|
|
|
|
*/
|
2017-05-18 04:07:26 +08:00
|
|
|
blkg_for_each_descendant_pre(blkg, pos_css,
|
2023-02-15 02:33:04 +08:00
|
|
|
global ? tg->td->queue->root_blkg : tg_to_blkg(tg)) {
|
2017-05-18 04:07:24 +08:00
|
|
|
struct throtl_grp *this_tg = blkg_to_tg(blkg);
|
|
|
|
struct throtl_grp *parent_tg;
|
|
|
|
|
|
|
|
tg_update_has_rules(this_tg);
|
|
|
|
/* ignore root/second level */
|
|
|
|
if (!cgroup_subsys_on_dfl(io_cgrp_subsys) || !blkg->parent ||
|
|
|
|
!blkg->parent->parent)
|
|
|
|
continue;
|
|
|
|
parent_tg = blkg_to_tg(blkg->parent);
|
|
|
|
/*
|
|
|
|
* make sure all children has lower idle time threshold and
|
|
|
|
* higher latency target
|
|
|
|
*/
|
|
|
|
this_tg->idletime_threshold = min(this_tg->idletime_threshold,
|
|
|
|
parent_tg->idletime_threshold);
|
|
|
|
this_tg->latency_target = max(this_tg->latency_target,
|
|
|
|
parent_tg->latency_target);
|
|
|
|
}
|
2023-11-17 10:35:22 +08:00
|
|
|
rcu_read_unlock();
|
2013-05-15 04:52:38 +08:00
|
|
|
|
2013-05-15 04:52:31 +08:00
|
|
|
/*
|
|
|
|
* We're already holding queue_lock and know @tg is valid. Let's
|
|
|
|
* apply the new config directly.
|
|
|
|
*
|
|
|
|
* Restart the slices for both READ and WRITES. It might happen
|
|
|
|
* that a group's limit are dropped suddenly and we don't want to
|
|
|
|
* account recently dispatched IO with new low rate.
|
|
|
|
*/
|
2022-08-29 10:22:40 +08:00
|
|
|
throtl_start_new_slice(tg, READ, false);
|
|
|
|
throtl_start_new_slice(tg, WRITE, false);
|
2013-05-15 04:52:31 +08:00
|
|
|
|
2013-05-15 04:52:32 +08:00
|
|
|
if (tg->flags & THROTL_TG_PENDING) {
|
2013-05-15 04:52:36 +08:00
|
|
|
tg_update_disptime(tg);
|
2013-05-15 04:52:37 +08:00
|
|
|
throtl_schedule_next_dispatch(sq->parent_sq, true);
|
2013-05-15 04:52:31 +08:00
|
|
|
}
|
2015-08-19 05:55:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t tg_set_conf(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes, loff_t off, bool is_u64)
|
|
|
|
{
|
|
|
|
struct blkcg *blkcg = css_to_blkcg(of_css(of));
|
|
|
|
struct blkg_conf_ctx ctx;
|
|
|
|
struct throtl_grp *tg;
|
|
|
|
int ret;
|
|
|
|
u64 v;
|
|
|
|
|
2023-04-13 08:06:47 +08:00
|
|
|
blkg_conf_init(&ctx, buf);
|
|
|
|
|
|
|
|
ret = blkg_conf_prep(blkcg, &blkcg_policy_throtl, &ctx);
|
2015-08-19 05:55:32 +08:00
|
|
|
if (ret)
|
2023-04-13 08:06:47 +08:00
|
|
|
goto out_finish;
|
2015-08-19 05:55:32 +08:00
|
|
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
if (sscanf(ctx.body, "%llu", &v) != 1)
|
|
|
|
goto out_finish;
|
|
|
|
if (!v)
|
2017-03-28 01:51:29 +08:00
|
|
|
v = U64_MAX;
|
2015-08-19 05:55:32 +08:00
|
|
|
|
|
|
|
tg = blkg_to_tg(ctx.blkg);
|
2022-08-29 10:22:40 +08:00
|
|
|
tg_update_carryover(tg);
|
2015-08-19 05:55:32 +08:00
|
|
|
|
|
|
|
if (is_u64)
|
|
|
|
*(u64 *)((void *)tg + of_cft(of)->private) = v;
|
|
|
|
else
|
|
|
|
*(unsigned int *)((void *)tg + of_cft(of)->private) = v;
|
2012-04-02 05:38:43 +08:00
|
|
|
|
2017-05-18 04:07:26 +08:00
|
|
|
tg_conf_updated(tg, false);
|
2015-08-19 05:55:31 +08:00
|
|
|
ret = 0;
|
|
|
|
out_finish:
|
2023-04-13 08:06:47 +08:00
|
|
|
blkg_conf_exit(&ctx);
|
2015-08-19 05:55:31 +08:00
|
|
|
return ret ?: nbytes;
|
2010-09-16 05:06:37 +08:00
|
|
|
}
|
|
|
|
|
2014-05-14 00:16:21 +08:00
|
|
|
static ssize_t tg_set_conf_u64(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes, loff_t off)
|
2012-04-02 05:38:43 +08:00
|
|
|
{
|
2014-05-14 00:16:21 +08:00
|
|
|
return tg_set_conf(of, buf, nbytes, off, true);
|
2012-04-02 05:38:43 +08:00
|
|
|
}
|
|
|
|
|
2014-05-14 00:16:21 +08:00
|
|
|
static ssize_t tg_set_conf_uint(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes, loff_t off)
|
2012-04-02 05:38:43 +08:00
|
|
|
{
|
2014-05-14 00:16:21 +08:00
|
|
|
return tg_set_conf(of, buf, nbytes, off, false);
|
2012-04-02 05:38:43 +08:00
|
|
|
}
|
|
|
|
|
2019-11-08 03:18:01 +08:00
|
|
|
static int tg_print_rwstat(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
blkg_prfill_rwstat, &blkcg_policy_throtl,
|
|
|
|
seq_cft(sf)->private, true);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 tg_prfill_rwstat_recursive(struct seq_file *sf,
|
|
|
|
struct blkg_policy_data *pd, int off)
|
|
|
|
{
|
|
|
|
struct blkg_rwstat_sample sum;
|
|
|
|
|
|
|
|
blkg_rwstat_recursive_sum(pd_to_blkg(pd), &blkcg_policy_throtl, off,
|
|
|
|
&sum);
|
|
|
|
return __blkg_prfill_rwstat(sf, pd, &sum);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int tg_print_rwstat_recursive(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
tg_prfill_rwstat_recursive, &blkcg_policy_throtl,
|
|
|
|
seq_cft(sf)->private, true);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-08-19 05:55:30 +08:00
|
|
|
static struct cftype throtl_legacy_files[] = {
|
2012-04-02 05:38:43 +08:00
|
|
|
{
|
|
|
|
.name = "throttle.read_bps_device",
|
2017-03-28 01:51:30 +08:00
|
|
|
.private = offsetof(struct throtl_grp, bps[READ][LIMIT_MAX]),
|
2013-12-06 01:28:04 +08:00
|
|
|
.seq_show = tg_print_conf_u64,
|
2014-05-14 00:16:21 +08:00
|
|
|
.write = tg_set_conf_u64,
|
2012-04-02 05:38:43 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.write_bps_device",
|
2017-03-28 01:51:30 +08:00
|
|
|
.private = offsetof(struct throtl_grp, bps[WRITE][LIMIT_MAX]),
|
2013-12-06 01:28:04 +08:00
|
|
|
.seq_show = tg_print_conf_u64,
|
2014-05-14 00:16:21 +08:00
|
|
|
.write = tg_set_conf_u64,
|
2012-04-02 05:38:43 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.read_iops_device",
|
2017-03-28 01:51:30 +08:00
|
|
|
.private = offsetof(struct throtl_grp, iops[READ][LIMIT_MAX]),
|
2013-12-06 01:28:04 +08:00
|
|
|
.seq_show = tg_print_conf_uint,
|
2014-05-14 00:16:21 +08:00
|
|
|
.write = tg_set_conf_uint,
|
2012-04-02 05:38:43 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.write_iops_device",
|
2017-03-28 01:51:30 +08:00
|
|
|
.private = offsetof(struct throtl_grp, iops[WRITE][LIMIT_MAX]),
|
2013-12-06 01:28:04 +08:00
|
|
|
.seq_show = tg_print_conf_uint,
|
2014-05-14 00:16:21 +08:00
|
|
|
.write = tg_set_conf_uint,
|
2012-04-02 05:38:43 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.io_service_bytes",
|
2019-11-08 03:18:01 +08:00
|
|
|
.private = offsetof(struct throtl_grp, stat_bytes),
|
|
|
|
.seq_show = tg_print_rwstat,
|
2012-04-02 05:38:43 +08:00
|
|
|
},
|
2017-12-11 22:56:25 +08:00
|
|
|
{
|
|
|
|
.name = "throttle.io_service_bytes_recursive",
|
2019-11-08 03:18:01 +08:00
|
|
|
.private = offsetof(struct throtl_grp, stat_bytes),
|
|
|
|
.seq_show = tg_print_rwstat_recursive,
|
2017-12-11 22:56:25 +08:00
|
|
|
},
|
2012-04-02 05:38:43 +08:00
|
|
|
{
|
|
|
|
.name = "throttle.io_serviced",
|
2019-11-08 03:18:01 +08:00
|
|
|
.private = offsetof(struct throtl_grp, stat_ios),
|
|
|
|
.seq_show = tg_print_rwstat,
|
2012-04-02 05:38:43 +08:00
|
|
|
},
|
2017-12-11 22:56:25 +08:00
|
|
|
{
|
|
|
|
.name = "throttle.io_serviced_recursive",
|
2019-11-08 03:18:01 +08:00
|
|
|
.private = offsetof(struct throtl_grp, stat_ios),
|
|
|
|
.seq_show = tg_print_rwstat_recursive,
|
2017-12-11 22:56:25 +08:00
|
|
|
},
|
2012-04-02 05:38:43 +08:00
|
|
|
{ } /* terminate */
|
|
|
|
};
|
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
static u64 tg_prfill_limit(struct seq_file *sf, struct blkg_policy_data *pd,
|
2015-08-19 05:55:34 +08:00
|
|
|
int off)
|
|
|
|
{
|
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
const char *dname = blkg_dev_name(pd->blkg);
|
|
|
|
char bufs[4][21] = { "max", "max", "max", "max" };
|
2017-03-28 01:51:32 +08:00
|
|
|
u64 bps_dft;
|
|
|
|
unsigned int iops_dft;
|
2017-03-28 01:51:42 +08:00
|
|
|
char idle_time[26] = "";
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
char latency_time[26] = "";
|
2015-08-19 05:55:34 +08:00
|
|
|
|
|
|
|
if (!dname)
|
|
|
|
return 0;
|
2017-03-28 01:51:30 +08:00
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
if (off == LIMIT_LOW) {
|
|
|
|
bps_dft = 0;
|
|
|
|
iops_dft = 0;
|
|
|
|
} else {
|
|
|
|
bps_dft = U64_MAX;
|
|
|
|
iops_dft = UINT_MAX;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tg->bps_conf[READ][off] == bps_dft &&
|
|
|
|
tg->bps_conf[WRITE][off] == bps_dft &&
|
|
|
|
tg->iops_conf[READ][off] == iops_dft &&
|
2017-03-28 01:51:42 +08:00
|
|
|
tg->iops_conf[WRITE][off] == iops_dft &&
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
(off != LIMIT_LOW ||
|
2017-05-18 04:07:27 +08:00
|
|
|
(tg->idletime_threshold_conf == DFL_IDLE_THRESHOLD &&
|
2017-05-18 04:07:24 +08:00
|
|
|
tg->latency_target_conf == DFL_LATENCY_TARGET)))
|
2015-08-19 05:55:34 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-05-18 04:07:26 +08:00
|
|
|
if (tg->bps_conf[READ][off] != U64_MAX)
|
2017-03-28 01:51:30 +08:00
|
|
|
snprintf(bufs[0], sizeof(bufs[0]), "%llu",
|
2017-03-28 01:51:32 +08:00
|
|
|
tg->bps_conf[READ][off]);
|
2017-05-18 04:07:26 +08:00
|
|
|
if (tg->bps_conf[WRITE][off] != U64_MAX)
|
2017-03-28 01:51:30 +08:00
|
|
|
snprintf(bufs[1], sizeof(bufs[1]), "%llu",
|
2017-03-28 01:51:32 +08:00
|
|
|
tg->bps_conf[WRITE][off]);
|
2017-05-18 04:07:26 +08:00
|
|
|
if (tg->iops_conf[READ][off] != UINT_MAX)
|
2017-03-28 01:51:30 +08:00
|
|
|
snprintf(bufs[2], sizeof(bufs[2]), "%u",
|
2017-03-28 01:51:32 +08:00
|
|
|
tg->iops_conf[READ][off]);
|
2017-05-18 04:07:26 +08:00
|
|
|
if (tg->iops_conf[WRITE][off] != UINT_MAX)
|
2017-03-28 01:51:30 +08:00
|
|
|
snprintf(bufs[3], sizeof(bufs[3]), "%u",
|
2017-03-28 01:51:32 +08:00
|
|
|
tg->iops_conf[WRITE][off]);
|
2017-03-28 01:51:42 +08:00
|
|
|
if (off == LIMIT_LOW) {
|
2017-05-18 04:07:24 +08:00
|
|
|
if (tg->idletime_threshold_conf == ULONG_MAX)
|
2017-03-28 01:51:42 +08:00
|
|
|
strcpy(idle_time, " idle=max");
|
|
|
|
else
|
|
|
|
snprintf(idle_time, sizeof(idle_time), " idle=%lu",
|
2017-05-18 04:07:24 +08:00
|
|
|
tg->idletime_threshold_conf);
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
|
2017-05-18 04:07:24 +08:00
|
|
|
if (tg->latency_target_conf == ULONG_MAX)
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
strcpy(latency_time, " latency=max");
|
|
|
|
else
|
|
|
|
snprintf(latency_time, sizeof(latency_time),
|
2017-05-18 04:07:24 +08:00
|
|
|
" latency=%lu", tg->latency_target_conf);
|
2017-03-28 01:51:42 +08:00
|
|
|
}
|
2015-08-19 05:55:34 +08:00
|
|
|
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
seq_printf(sf, "%s rbps=%s wbps=%s riops=%s wiops=%s%s%s\n",
|
|
|
|
dname, bufs[0], bufs[1], bufs[2], bufs[3], idle_time,
|
|
|
|
latency_time);
|
2015-08-19 05:55:34 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
static int tg_print_limit(struct seq_file *sf, void *v)
|
2015-08-19 05:55:34 +08:00
|
|
|
{
|
2017-03-28 01:51:32 +08:00
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), tg_prfill_limit,
|
2015-08-19 05:55:34 +08:00
|
|
|
&blkcg_policy_throtl, seq_cft(sf)->private, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
static ssize_t tg_set_limit(struct kernfs_open_file *of,
|
2015-08-19 05:55:34 +08:00
|
|
|
char *buf, size_t nbytes, loff_t off)
|
|
|
|
{
|
|
|
|
struct blkcg *blkcg = css_to_blkcg(of_css(of));
|
|
|
|
struct blkg_conf_ctx ctx;
|
|
|
|
struct throtl_grp *tg;
|
|
|
|
u64 v[4];
|
2017-03-28 01:51:42 +08:00
|
|
|
unsigned long idle_time;
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
unsigned long latency_time;
|
2015-08-19 05:55:34 +08:00
|
|
|
int ret;
|
2017-03-28 01:51:32 +08:00
|
|
|
int index = of_cft(of)->private;
|
2015-08-19 05:55:34 +08:00
|
|
|
|
2023-04-13 08:06:47 +08:00
|
|
|
blkg_conf_init(&ctx, buf);
|
|
|
|
|
|
|
|
ret = blkg_conf_prep(blkcg, &blkcg_policy_throtl, &ctx);
|
2015-08-19 05:55:34 +08:00
|
|
|
if (ret)
|
2023-04-13 08:06:47 +08:00
|
|
|
goto out_finish;
|
2015-08-19 05:55:34 +08:00
|
|
|
|
|
|
|
tg = blkg_to_tg(ctx.blkg);
|
2022-08-29 10:22:40 +08:00
|
|
|
tg_update_carryover(tg);
|
2015-08-19 05:55:34 +08:00
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
v[0] = tg->bps_conf[READ][index];
|
|
|
|
v[1] = tg->bps_conf[WRITE][index];
|
|
|
|
v[2] = tg->iops_conf[READ][index];
|
|
|
|
v[3] = tg->iops_conf[WRITE][index];
|
2015-08-19 05:55:34 +08:00
|
|
|
|
2017-05-18 04:07:24 +08:00
|
|
|
idle_time = tg->idletime_threshold_conf;
|
|
|
|
latency_time = tg->latency_target_conf;
|
2015-08-19 05:55:34 +08:00
|
|
|
while (true) {
|
|
|
|
char tok[27]; /* wiops=18446744073709551616 */
|
|
|
|
char *p;
|
2017-03-28 01:51:29 +08:00
|
|
|
u64 val = U64_MAX;
|
2015-08-19 05:55:34 +08:00
|
|
|
int len;
|
|
|
|
|
|
|
|
if (sscanf(ctx.body, "%26s%n", tok, &len) != 1)
|
|
|
|
break;
|
|
|
|
if (tok[0] == '\0')
|
|
|
|
break;
|
|
|
|
ctx.body += len;
|
|
|
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
p = tok;
|
|
|
|
strsep(&p, "=");
|
|
|
|
if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max")))
|
|
|
|
goto out_finish;
|
|
|
|
|
|
|
|
ret = -ERANGE;
|
|
|
|
if (!val)
|
|
|
|
goto out_finish;
|
|
|
|
|
|
|
|
ret = -EINVAL;
|
2020-10-08 11:52:25 +08:00
|
|
|
if (!strcmp(tok, "rbps") && val > 1)
|
2015-08-19 05:55:34 +08:00
|
|
|
v[0] = val;
|
2020-10-08 11:52:25 +08:00
|
|
|
else if (!strcmp(tok, "wbps") && val > 1)
|
2015-08-19 05:55:34 +08:00
|
|
|
v[1] = val;
|
2020-10-08 11:52:25 +08:00
|
|
|
else if (!strcmp(tok, "riops") && val > 1)
|
2015-08-19 05:55:34 +08:00
|
|
|
v[2] = min_t(u64, val, UINT_MAX);
|
2020-10-08 11:52:25 +08:00
|
|
|
else if (!strcmp(tok, "wiops") && val > 1)
|
2015-08-19 05:55:34 +08:00
|
|
|
v[3] = min_t(u64, val, UINT_MAX);
|
2017-03-28 01:51:42 +08:00
|
|
|
else if (off == LIMIT_LOW && !strcmp(tok, "idle"))
|
|
|
|
idle_time = val;
|
blk-throttle: add interface for per-cgroup target latency
Here we introduce per-cgroup latency target. The target determines how a
cgroup can afford latency increasement. We will use the target latency
to calculate a threshold and use it to schedule IO for cgroups. If a
cgroup's bandwidth is below its low limit but its average latency is
below the threshold, other cgroups can safely dispatch more IO even
their bandwidth is higher than their low limits. On the other hand, if
the first cgroup's latency is higher than the threshold, other cgroups
are throttled to their low limits. So the target latency determines how
we efficiently utilize free disk resource without sacifice of worload's
IO latency.
For example, assume 4k IO average latency is 50us when disk isn't
congested. A cgroup sets the target latency to 30us. Then the cgroup can
accept 50+30=80us IO latency. If the cgroupt's average IO latency is
90us and its bandwidth is below low limit, other cgroups are throttled
to their low limit. If the cgroup's average IO latency is 60us, other
cgroups are allowed to dispatch more IO. When other cgroups dispatch
more IO, the first cgroup's IO latency will increase. If it increases to
81us, we then throttle other cgroups.
User will configure the interface in this way:
echo "8:16 rbps=2097152 wbps=max latency=100 idle=200" > io.low
latency is in microsecond unit
By default, latency target is 0, which means to guarantee IO latency.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:44 +08:00
|
|
|
else if (off == LIMIT_LOW && !strcmp(tok, "latency"))
|
|
|
|
latency_time = val;
|
2015-08-19 05:55:34 +08:00
|
|
|
else
|
|
|
|
goto out_finish;
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
tg->bps_conf[READ][index] = v[0];
|
|
|
|
tg->bps_conf[WRITE][index] = v[1];
|
|
|
|
tg->iops_conf[READ][index] = v[2];
|
|
|
|
tg->iops_conf[WRITE][index] = v[3];
|
2015-08-19 05:55:34 +08:00
|
|
|
|
2017-03-28 01:51:32 +08:00
|
|
|
if (index == LIMIT_MAX) {
|
|
|
|
tg->bps[READ][index] = v[0];
|
|
|
|
tg->bps[WRITE][index] = v[1];
|
|
|
|
tg->iops[READ][index] = v[2];
|
|
|
|
tg->iops[WRITE][index] = v[3];
|
|
|
|
}
|
|
|
|
tg->bps[READ][LIMIT_LOW] = min(tg->bps_conf[READ][LIMIT_LOW],
|
|
|
|
tg->bps_conf[READ][LIMIT_MAX]);
|
|
|
|
tg->bps[WRITE][LIMIT_LOW] = min(tg->bps_conf[WRITE][LIMIT_LOW],
|
|
|
|
tg->bps_conf[WRITE][LIMIT_MAX]);
|
|
|
|
tg->iops[READ][LIMIT_LOW] = min(tg->iops_conf[READ][LIMIT_LOW],
|
|
|
|
tg->iops_conf[READ][LIMIT_MAX]);
|
|
|
|
tg->iops[WRITE][LIMIT_LOW] = min(tg->iops_conf[WRITE][LIMIT_LOW],
|
|
|
|
tg->iops_conf[WRITE][LIMIT_MAX]);
|
2017-05-18 04:07:27 +08:00
|
|
|
tg->idletime_threshold_conf = idle_time;
|
|
|
|
tg->latency_target_conf = latency_time;
|
|
|
|
|
|
|
|
/* force user to configure all settings for low limit */
|
|
|
|
if (!(tg->bps[READ][LIMIT_LOW] || tg->iops[READ][LIMIT_LOW] ||
|
|
|
|
tg->bps[WRITE][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW]) ||
|
|
|
|
tg->idletime_threshold_conf == DFL_IDLE_THRESHOLD ||
|
|
|
|
tg->latency_target_conf == DFL_LATENCY_TARGET) {
|
|
|
|
tg->bps[READ][LIMIT_LOW] = 0;
|
|
|
|
tg->bps[WRITE][LIMIT_LOW] = 0;
|
|
|
|
tg->iops[READ][LIMIT_LOW] = 0;
|
|
|
|
tg->iops[WRITE][LIMIT_LOW] = 0;
|
|
|
|
tg->idletime_threshold = DFL_IDLE_THRESHOLD;
|
|
|
|
tg->latency_target = DFL_LATENCY_TARGET;
|
|
|
|
} else if (index == LIMIT_LOW) {
|
2017-05-18 04:07:24 +08:00
|
|
|
tg->idletime_threshold = tg->idletime_threshold_conf;
|
|
|
|
tg->latency_target = tg->latency_target_conf;
|
2017-03-28 01:51:32 +08:00
|
|
|
}
|
2017-05-18 04:07:27 +08:00
|
|
|
|
|
|
|
blk_throtl_update_limit_valid(tg->td);
|
|
|
|
if (tg->td->limit_valid[LIMIT_LOW]) {
|
|
|
|
if (index == LIMIT_LOW)
|
|
|
|
tg->td->limit_index = LIMIT_LOW;
|
|
|
|
} else
|
|
|
|
tg->td->limit_index = LIMIT_MAX;
|
2017-05-18 04:07:26 +08:00
|
|
|
tg_conf_updated(tg, index == LIMIT_LOW &&
|
|
|
|
tg->td->limit_valid[LIMIT_LOW]);
|
2015-08-19 05:55:34 +08:00
|
|
|
ret = 0;
|
|
|
|
out_finish:
|
2023-04-13 08:06:47 +08:00
|
|
|
blkg_conf_exit(&ctx);
|
2015-08-19 05:55:34 +08:00
|
|
|
return ret ?: nbytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct cftype throtl_files[] = {
|
2017-03-28 01:51:32 +08:00
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
{
|
|
|
|
.name = "low",
|
|
|
|
.flags = CFTYPE_NOT_ON_ROOT,
|
|
|
|
.seq_show = tg_print_limit,
|
|
|
|
.write = tg_set_limit,
|
|
|
|
.private = LIMIT_LOW,
|
|
|
|
},
|
|
|
|
#endif
|
2015-08-19 05:55:34 +08:00
|
|
|
{
|
|
|
|
.name = "max",
|
|
|
|
.flags = CFTYPE_NOT_ON_ROOT,
|
2017-03-28 01:51:32 +08:00
|
|
|
.seq_show = tg_print_limit,
|
|
|
|
.write = tg_set_limit,
|
|
|
|
.private = LIMIT_MAX,
|
2015-08-19 05:55:34 +08:00
|
|
|
},
|
|
|
|
{ } /* terminate */
|
|
|
|
};
|
|
|
|
|
2011-03-03 08:05:33 +08:00
|
|
|
static void throtl_shutdown_wq(struct request_queue *q)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
|
|
|
struct throtl_data *td = q->td;
|
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
cancel_work_sync(&td->dispatch_work);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2021-10-05 23:11:56 +08:00
|
|
|
struct blkcg_policy blkcg_policy_throtl = {
|
2015-08-19 05:55:34 +08:00
|
|
|
.dfl_cftypes = throtl_files,
|
2015-08-19 05:55:30 +08:00
|
|
|
.legacy_cftypes = throtl_legacy_files,
|
2012-04-17 04:57:27 +08:00
|
|
|
|
2015-08-19 05:55:11 +08:00
|
|
|
.pd_alloc_fn = throtl_pd_alloc,
|
2012-04-17 04:57:27 +08:00
|
|
|
.pd_init_fn = throtl_pd_init,
|
2013-05-15 04:52:38 +08:00
|
|
|
.pd_online_fn = throtl_pd_online,
|
2017-03-28 01:51:32 +08:00
|
|
|
.pd_offline_fn = throtl_pd_offline,
|
2015-08-19 05:55:11 +08:00
|
|
|
.pd_free_fn = throtl_pd_free,
|
2010-09-16 05:06:35 +08:00
|
|
|
};
|
|
|
|
|
2022-09-22 02:04:58 +08:00
|
|
|
void blk_throtl_cancel_bios(struct gendisk *disk)
|
2022-09-03 14:28:26 +08:00
|
|
|
{
|
2022-09-22 02:04:58 +08:00
|
|
|
struct request_queue *q = disk->queue;
|
2022-09-03 14:28:26 +08:00
|
|
|
struct cgroup_subsys_state *pos_css;
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
|
|
|
|
spin_lock_irq(&q->queue_lock);
|
|
|
|
/*
|
|
|
|
* queue_lock is held, rcu lock is not needed here technically.
|
|
|
|
* However, rcu lock is still held to emphasize that following
|
|
|
|
* path need RCU protection and to prevent warning from lockdep.
|
|
|
|
*/
|
|
|
|
rcu_read_lock();
|
2023-02-15 02:33:04 +08:00
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, q->root_blkg) {
|
2022-09-03 14:28:26 +08:00
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg);
|
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the flag to make sure throtl_pending_timer_fn() won't
|
|
|
|
* stop until all throttled bios are dispatched.
|
|
|
|
*/
|
2022-12-05 19:57:03 +08:00
|
|
|
tg->flags |= THROTL_TG_CANCELING;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do not dispatch cgroup without THROTL_TG_PENDING or cgroup
|
|
|
|
* will be inserted to service queue without THROTL_TG_PENDING
|
|
|
|
* set in tg_update_disptime below. Then IO dispatched from
|
|
|
|
* child in tg_dispatch_one_bio will trigger double insertion
|
|
|
|
* and corrupt the tree.
|
|
|
|
*/
|
|
|
|
if (!(tg->flags & THROTL_TG_PENDING))
|
|
|
|
continue;
|
|
|
|
|
2022-09-03 14:28:26 +08:00
|
|
|
/*
|
|
|
|
* Update disptime after setting the above flag to make sure
|
|
|
|
* throtl_select_dispatch() won't exit without dispatching.
|
|
|
|
*/
|
|
|
|
tg_update_disptime(tg);
|
|
|
|
|
|
|
|
throtl_schedule_pending_timer(sq, jiffies + 1);
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
spin_unlock_irq(&q->queue_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
2017-03-28 01:51:35 +08:00
|
|
|
static unsigned long __tg_last_low_overflow_time(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
unsigned long rtime = jiffies, wtime = jiffies;
|
|
|
|
|
|
|
|
if (tg->bps[READ][LIMIT_LOW] || tg->iops[READ][LIMIT_LOW])
|
|
|
|
rtime = tg->last_low_overflow_time[READ];
|
|
|
|
if (tg->bps[WRITE][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW])
|
|
|
|
wtime = tg->last_low_overflow_time[WRITE];
|
|
|
|
return min(rtime, wtime);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long tg_last_low_overflow_time(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
struct throtl_service_queue *parent_sq;
|
|
|
|
struct throtl_grp *parent = tg;
|
|
|
|
unsigned long ret = __tg_last_low_overflow_time(tg);
|
|
|
|
|
|
|
|
while (true) {
|
|
|
|
parent_sq = parent->service_queue.parent_sq;
|
|
|
|
parent = sq_to_tg(parent_sq);
|
|
|
|
if (!parent)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The parent doesn't have low limit, it always reaches low
|
|
|
|
* limit. Its overflow time is useless for children
|
|
|
|
*/
|
|
|
|
if (!parent->bps[READ][LIMIT_LOW] &&
|
|
|
|
!parent->iops[READ][LIMIT_LOW] &&
|
|
|
|
!parent->bps[WRITE][LIMIT_LOW] &&
|
|
|
|
!parent->iops[WRITE][LIMIT_LOW])
|
|
|
|
continue;
|
|
|
|
if (time_after(__tg_last_low_overflow_time(parent), ret))
|
|
|
|
ret = __tg_last_low_overflow_time(parent);
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
static bool throtl_tg_is_idle(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* cgroup is idle if:
|
|
|
|
* - single idle is too long, longer than a fixed value (in case user
|
2017-05-18 04:07:27 +08:00
|
|
|
* configure a too big threshold) or 4 times of idletime threshold
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
* - average think time is more than threshold
|
2017-03-28 06:19:43 +08:00
|
|
|
* - IO latency is largely below threshold
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
*/
|
2017-05-18 04:07:27 +08:00
|
|
|
unsigned long time;
|
2017-05-18 04:07:25 +08:00
|
|
|
bool ret;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
|
2017-05-18 04:07:27 +08:00
|
|
|
time = min_t(unsigned long, MAX_IDLE_TIME, 4 * tg->idletime_threshold);
|
|
|
|
ret = tg->latency_target == DFL_LATENCY_TARGET ||
|
|
|
|
tg->idletime_threshold == DFL_IDLE_THRESHOLD ||
|
|
|
|
(ktime_get_ns() >> 10) - tg->last_finish_time > time ||
|
|
|
|
tg->avg_idletime > tg->idletime_threshold ||
|
|
|
|
(tg->latency_target && tg->bio_cnt &&
|
2017-03-28 06:19:43 +08:00
|
|
|
tg->bad_bio_cnt * 5 < tg->bio_cnt);
|
2017-05-18 04:07:25 +08:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"avg_idle=%ld, idle_threshold=%ld, bad_bio=%d, total_bio=%d, is_idle=%d, scale=%d",
|
|
|
|
tg->avg_idletime, tg->idletime_threshold, tg->bad_bio_cnt,
|
|
|
|
tg->bio_cnt, ret, tg->td->scale);
|
|
|
|
return ret;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
}
|
|
|
|
|
2022-12-05 19:57:05 +08:00
|
|
|
static bool throtl_low_limit_reached(struct throtl_grp *tg, int rw)
|
2017-03-28 01:51:34 +08:00
|
|
|
{
|
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2022-12-05 19:57:05 +08:00
|
|
|
bool limit = tg->bps[rw][LIMIT_LOW] || tg->iops[rw][LIMIT_LOW];
|
2017-03-28 01:51:34 +08:00
|
|
|
|
|
|
|
/*
|
2022-12-05 19:57:05 +08:00
|
|
|
* if low limit is zero, low limit is always reached.
|
|
|
|
* if low limit is non-zero, we can check if there is any request
|
|
|
|
* is queued to determine if low limit is reached as we throttle
|
|
|
|
* request according to limit.
|
2017-03-28 01:51:34 +08:00
|
|
|
*/
|
2022-12-05 19:57:05 +08:00
|
|
|
return !limit || sq->nr_queued[rw];
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_tg_can_upgrade(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* cgroup reaches low limit when low limit of READ and WRITE are
|
|
|
|
* both reached, it's ok to upgrade to next limit if cgroup reaches
|
|
|
|
* low limit
|
|
|
|
*/
|
|
|
|
if (throtl_low_limit_reached(tg, READ) &&
|
|
|
|
throtl_low_limit_reached(tg, WRITE))
|
2017-03-28 01:51:34 +08:00
|
|
|
return true;
|
2017-03-28 01:51:39 +08:00
|
|
|
|
|
|
|
if (time_after_eq(jiffies,
|
2017-03-28 01:51:43 +08:00
|
|
|
tg_last_low_overflow_time(tg) + tg->td->throtl_slice) &&
|
|
|
|
throtl_tg_is_idle(tg))
|
2017-03-28 01:51:39 +08:00
|
|
|
return true;
|
2017-03-28 01:51:34 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_hierarchy_can_upgrade(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
while (true) {
|
|
|
|
if (throtl_tg_can_upgrade(tg))
|
|
|
|
return true;
|
|
|
|
tg = sq_to_tg(tg->service_queue.parent_sq);
|
|
|
|
if (!tg || !tg_to_blkg(tg)->parent)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_can_upgrade(struct throtl_data *td,
|
|
|
|
struct throtl_grp *this_tg)
|
|
|
|
{
|
|
|
|
struct cgroup_subsys_state *pos_css;
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
|
|
|
|
if (td->limit_index != LIMIT_LOW)
|
|
|
|
return false;
|
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
if (time_before(jiffies, td->low_downgrade_time + td->throtl_slice))
|
2017-03-28 01:51:35 +08:00
|
|
|
return false;
|
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
rcu_read_lock();
|
2023-02-15 02:33:04 +08:00
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg) {
|
2017-03-28 01:51:34 +08:00
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg);
|
|
|
|
|
|
|
|
if (tg == this_tg)
|
|
|
|
continue;
|
|
|
|
if (!list_empty(&tg_to_blkg(tg)->blkcg->css.children))
|
|
|
|
continue;
|
|
|
|
if (!throtl_hierarchy_can_upgrade(tg)) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:43 +08:00
|
|
|
static void throtl_upgrade_check(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
unsigned long now = jiffies;
|
|
|
|
|
|
|
|
if (tg->td->limit_index != LIMIT_LOW)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (time_after(tg->last_check_time + tg->td->throtl_slice, now))
|
|
|
|
return;
|
|
|
|
|
|
|
|
tg->last_check_time = now;
|
|
|
|
|
|
|
|
if (!time_after_eq(now,
|
|
|
|
__tg_last_low_overflow_time(tg) + tg->td->throtl_slice))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (throtl_can_upgrade(tg->td, NULL))
|
|
|
|
throtl_upgrade_state(tg->td);
|
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
static void throtl_upgrade_state(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
struct cgroup_subsys_state *pos_css;
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
|
2017-05-18 04:07:25 +08:00
|
|
|
throtl_log(&td->service_queue, "upgrade to max");
|
2017-03-28 01:51:34 +08:00
|
|
|
td->limit_index = LIMIT_MAX;
|
2017-03-28 01:51:35 +08:00
|
|
|
td->low_upgrade_time = jiffies;
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
td->scale = 0;
|
2017-03-28 01:51:34 +08:00
|
|
|
rcu_read_lock();
|
2023-02-15 02:33:04 +08:00
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg) {
|
2017-03-28 01:51:34 +08:00
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg);
|
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
|
|
|
|
|
|
|
tg->disptime = jiffies - 1;
|
|
|
|
throtl_select_dispatch(sq);
|
blk-throttle: fix possible io stall when upgrade to max
There is a case which will lead to io stall. The case is described as
follows.
/test1
|-subtest1
/test2
|-subtest2
And subtest1 and subtest2 each has 32 queued bios already.
Now upgrade to max. In throtl_upgrade_state, it will try to dispatch
bios as follows:
1) tg=subtest1, do nothing;
2) tg=test1, transfer 32 queued bios from subtest1 to test1; no pending
left, no need to schedule next dispatch;
3) tg=subtest2, do nothing;
4) tg=test2, transfer 32 queued bios from subtest2 to test2; no pending
left, no need to schedule next dispatch;
5) tg=/, transfer 8 queued bios from test1 to /, 8 queued bios from
test2 to /, 8 queued bios from test1 to /, and 8 queued bios from test2
to /; note that test1 and test2 each still has 16 queued bios left;
6) tg=/, try to schedule next dispatch, but since disptime is now
(update in tg_update_disptime, wait=0), pending timer is not scheduled
in fact;
7) In throtl_upgrade_state it totally dispatches 32 queued bios and with
32 left. test1 and test2 each has 16 queued bios;
8) throtl_pending_timer_fn sees the left over bios, but could do
nothing, because throtl_select_dispatch returns 0, and test1/test2 has
no pending tg.
The blktrace shows the following:
8,32 0 0 2.539007641 0 m N throtl upgrade to max
8,32 0 0 2.539072267 0 m N throtl /test2 dispatch nr_queued=16 read=0 write=16
8,32 7 0 2.539077142 0 m N throtl /test1 dispatch nr_queued=16 read=0 write=16
So force schedule dispatch if there are pending children.
Reviewed-by: Shaohua Li <shli@fb.com>
Signed-off-by: Joseph Qi <qijiang.qj@alibaba-inc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-09-30 14:38:49 +08:00
|
|
|
throtl_schedule_next_dispatch(sq, true);
|
2017-03-28 01:51:34 +08:00
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
throtl_select_dispatch(&td->service_queue);
|
blk-throttle: fix possible io stall when upgrade to max
There is a case which will lead to io stall. The case is described as
follows.
/test1
|-subtest1
/test2
|-subtest2
And subtest1 and subtest2 each has 32 queued bios already.
Now upgrade to max. In throtl_upgrade_state, it will try to dispatch
bios as follows:
1) tg=subtest1, do nothing;
2) tg=test1, transfer 32 queued bios from subtest1 to test1; no pending
left, no need to schedule next dispatch;
3) tg=subtest2, do nothing;
4) tg=test2, transfer 32 queued bios from subtest2 to test2; no pending
left, no need to schedule next dispatch;
5) tg=/, transfer 8 queued bios from test1 to /, 8 queued bios from
test2 to /, 8 queued bios from test1 to /, and 8 queued bios from test2
to /; note that test1 and test2 each still has 16 queued bios left;
6) tg=/, try to schedule next dispatch, but since disptime is now
(update in tg_update_disptime, wait=0), pending timer is not scheduled
in fact;
7) In throtl_upgrade_state it totally dispatches 32 queued bios and with
32 left. test1 and test2 each has 16 queued bios;
8) throtl_pending_timer_fn sees the left over bios, but could do
nothing, because throtl_select_dispatch returns 0, and test1/test2 has
no pending tg.
The blktrace shows the following:
8,32 0 0 2.539007641 0 m N throtl upgrade to max
8,32 0 0 2.539072267 0 m N throtl /test2 dispatch nr_queued=16 read=0 write=16
8,32 7 0 2.539077142 0 m N throtl /test1 dispatch nr_queued=16 read=0 write=16
So force schedule dispatch if there are pending children.
Reviewed-by: Shaohua Li <shli@fb.com>
Signed-off-by: Joseph Qi <qijiang.qj@alibaba-inc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-09-30 14:38:49 +08:00
|
|
|
throtl_schedule_next_dispatch(&td->service_queue, true);
|
2017-03-28 01:51:34 +08:00
|
|
|
queue_work(kthrotld_workqueue, &td->dispatch_work);
|
|
|
|
}
|
|
|
|
|
2020-10-08 11:52:22 +08:00
|
|
|
static void throtl_downgrade_state(struct throtl_data *td)
|
2017-03-28 01:51:35 +08:00
|
|
|
{
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
td->scale /= 2;
|
|
|
|
|
2017-05-18 04:07:25 +08:00
|
|
|
throtl_log(&td->service_queue, "downgrade, scale %d", td->scale);
|
blk-throttle: make bandwidth change smooth
When cgroups all reach low limit, cgroups can dispatch more IO. This
could make some cgroups dispatch more IO but others not, and even some
cgroups could dispatch less IO than their low limit. For example, cg1
low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is
120M/s for the workload. Their bps could something like this:
cg1/cg2 bps: T1: 10/80 -> T2: 60/60 -> T3: 10/80
At T1, all cgroups reach low limit, so they can dispatch more IO later.
Then cg1 dispatch more IO and cg2 has no room to dispatch enough IO. At
T2, cg2 only dispatches 60M/s. Since We detect cg2 dispatches less IO
than its low limit 80M/s, we downgrade the queue from LIMIT_MAX to
LIMIT_LOW, then all cgroups are throttled to their low limit (T3). cg2
will have bandwidth below its low limit at most time.
The big problem here is we don't know the maximum bandwidth of the
workload, so we can't make smart decision to avoid the situation. This
patch makes cgroup bandwidth change smooth. After disk upgrades from
LIMIT_LOW to LIMIT_MAX, we don't allow cgroups use all bandwidth upto
their max limit immediately. Their bandwidth limit will be increased
gradually to avoid above situation. So above example will became
something like:
cg1/cg2 bps: 10/80 -> 15/105 -> 20/100 -> 25/95 -> 30/90 -> 35/85 -> 40/80
-> 45/75 -> 22/98
In this way cgroups bandwidth will be above their limit in majority
time, this still doesn't fully utilize disk bandwidth, but that's
something we pay for sharing.
Scale up is linear. The limit scales up 1/2 .low limit every
throtl_slice after upgrade. The scale up will stop if the adjusted limit
hits .max limit. Scale down is exponential. We cut the scale value half
if a cgroup doesn't hit its .low limit. If the scale becomes 0, we then
fully downgrade the queue to LIMIT_LOW state.
Note this doesn't completely avoid cgroup running under its low limit.
The best way to guarantee cgroup doesn't run under its limit is to set
max limit. For example, if we set cg1 max limit to 40, cg2 will never
run under its low limit.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:40 +08:00
|
|
|
if (td->scale) {
|
|
|
|
td->low_upgrade_time = jiffies - td->scale * td->throtl_slice;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-10-08 11:52:22 +08:00
|
|
|
td->limit_index = LIMIT_LOW;
|
2017-03-28 01:51:35 +08:00
|
|
|
td->low_downgrade_time = jiffies;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_tg_can_downgrade(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
struct throtl_data *td = tg->td;
|
|
|
|
unsigned long now = jiffies;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If cgroup is below low limit, consider downgrade and throttle other
|
|
|
|
* cgroups
|
|
|
|
*/
|
2022-12-05 19:57:08 +08:00
|
|
|
if (time_after_eq(now, tg_last_low_overflow_time(tg) +
|
2017-03-28 01:51:43 +08:00
|
|
|
td->throtl_slice) &&
|
|
|
|
(!throtl_tg_is_idle(tg) ||
|
|
|
|
!list_empty(&tg_to_blkg(tg)->blkcg->css.children)))
|
2017-03-28 01:51:35 +08:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_hierarchy_can_downgrade(struct throtl_grp *tg)
|
|
|
|
{
|
2022-12-05 19:57:08 +08:00
|
|
|
struct throtl_data *td = tg->td;
|
|
|
|
|
|
|
|
if (time_before(jiffies, td->low_upgrade_time + td->throtl_slice))
|
|
|
|
return false;
|
|
|
|
|
2017-03-28 01:51:35 +08:00
|
|
|
while (true) {
|
|
|
|
if (!throtl_tg_can_downgrade(tg))
|
|
|
|
return false;
|
|
|
|
tg = sq_to_tg(tg->service_queue.parent_sq);
|
|
|
|
if (!tg || !tg_to_blkg(tg)->parent)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void throtl_downgrade_check(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
uint64_t bps;
|
|
|
|
unsigned int iops;
|
|
|
|
unsigned long elapsed_time;
|
|
|
|
unsigned long now = jiffies;
|
|
|
|
|
|
|
|
if (tg->td->limit_index != LIMIT_MAX ||
|
|
|
|
!tg->td->limit_valid[LIMIT_LOW])
|
|
|
|
return;
|
|
|
|
if (!list_empty(&tg_to_blkg(tg)->blkcg->css.children))
|
|
|
|
return;
|
2017-03-28 01:51:37 +08:00
|
|
|
if (time_after(tg->last_check_time + tg->td->throtl_slice, now))
|
2017-03-28 01:51:35 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
elapsed_time = now - tg->last_check_time;
|
|
|
|
tg->last_check_time = now;
|
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
if (time_before(now, tg_last_low_overflow_time(tg) +
|
|
|
|
tg->td->throtl_slice))
|
2017-03-28 01:51:35 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (tg->bps[READ][LIMIT_LOW]) {
|
|
|
|
bps = tg->last_bytes_disp[READ] * HZ;
|
|
|
|
do_div(bps, elapsed_time);
|
|
|
|
if (bps >= tg->bps[READ][LIMIT_LOW])
|
|
|
|
tg->last_low_overflow_time[READ] = now;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tg->bps[WRITE][LIMIT_LOW]) {
|
|
|
|
bps = tg->last_bytes_disp[WRITE] * HZ;
|
|
|
|
do_div(bps, elapsed_time);
|
|
|
|
if (bps >= tg->bps[WRITE][LIMIT_LOW])
|
|
|
|
tg->last_low_overflow_time[WRITE] = now;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tg->iops[READ][LIMIT_LOW]) {
|
|
|
|
iops = tg->last_io_disp[READ] * HZ / elapsed_time;
|
|
|
|
if (iops >= tg->iops[READ][LIMIT_LOW])
|
|
|
|
tg->last_low_overflow_time[READ] = now;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tg->iops[WRITE][LIMIT_LOW]) {
|
|
|
|
iops = tg->last_io_disp[WRITE] * HZ / elapsed_time;
|
|
|
|
if (iops >= tg->iops[WRITE][LIMIT_LOW])
|
|
|
|
tg->last_low_overflow_time[WRITE] = now;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If cgroup is below low limit, consider downgrade and throttle other
|
|
|
|
* cgroups
|
|
|
|
*/
|
|
|
|
if (throtl_hierarchy_can_downgrade(tg))
|
2020-10-08 11:52:22 +08:00
|
|
|
throtl_downgrade_state(tg->td);
|
2017-03-28 01:51:35 +08:00
|
|
|
|
|
|
|
tg->last_bytes_disp[READ] = 0;
|
|
|
|
tg->last_bytes_disp[WRITE] = 0;
|
|
|
|
tg->last_io_disp[READ] = 0;
|
|
|
|
tg->last_io_disp[WRITE] = 0;
|
|
|
|
}
|
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
static void blk_throtl_update_idletime(struct throtl_grp *tg)
|
|
|
|
{
|
2020-10-08 11:52:23 +08:00
|
|
|
unsigned long now;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
unsigned long last_finish_time = tg->last_finish_time;
|
|
|
|
|
2020-10-08 11:52:23 +08:00
|
|
|
if (last_finish_time == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
now = ktime_get_ns() >> 10;
|
|
|
|
if (now <= last_finish_time ||
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
last_finish_time == tg->checked_last_finish_time)
|
|
|
|
return;
|
|
|
|
|
|
|
|
tg->avg_idletime = (tg->avg_idletime * 7 + now - last_finish_time) >> 3;
|
|
|
|
tg->checked_last_finish_time = last_finish_time;
|
|
|
|
}
|
|
|
|
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
static void throtl_update_latency_buckets(struct throtl_data *td)
|
|
|
|
{
|
2017-11-21 09:38:30 +08:00
|
|
|
struct avg_latency_bucket avg_latency[2][LATENCY_BUCKET_SIZE];
|
|
|
|
int i, cpu, rw;
|
|
|
|
unsigned long last_latency[2] = { 0 };
|
|
|
|
unsigned long latency[2];
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2020-10-08 11:52:24 +08:00
|
|
|
if (!blk_queue_nonrot(td->queue) || !td->limit_valid[LIMIT_LOW])
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
return;
|
|
|
|
if (time_before(jiffies, td->last_calculate_time + HZ))
|
|
|
|
return;
|
|
|
|
td->last_calculate_time = jiffies;
|
|
|
|
|
|
|
|
memset(avg_latency, 0, sizeof(avg_latency));
|
2017-11-21 09:38:30 +08:00
|
|
|
for (rw = READ; rw <= WRITE; rw++) {
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++) {
|
|
|
|
struct latency_bucket *tmp = &td->tmp_buckets[rw][i];
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct latency_bucket *bucket;
|
|
|
|
|
|
|
|
/* this isn't race free, but ok in practice */
|
|
|
|
bucket = per_cpu_ptr(td->latency_buckets[rw],
|
|
|
|
cpu);
|
|
|
|
tmp->total_latency += bucket[i].total_latency;
|
|
|
|
tmp->samples += bucket[i].samples;
|
|
|
|
bucket[i].total_latency = 0;
|
|
|
|
bucket[i].samples = 0;
|
|
|
|
}
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
if (tmp->samples >= 32) {
|
|
|
|
int samples = tmp->samples;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
latency[rw] = tmp->total_latency;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
tmp->total_latency = 0;
|
|
|
|
tmp->samples = 0;
|
|
|
|
latency[rw] /= samples;
|
|
|
|
if (latency[rw] == 0)
|
|
|
|
continue;
|
|
|
|
avg_latency[rw][i].latency = latency[rw];
|
|
|
|
}
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
for (rw = READ; rw <= WRITE; rw++) {
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++) {
|
|
|
|
if (!avg_latency[rw][i].latency) {
|
|
|
|
if (td->avg_buckets[rw][i].latency < last_latency[rw])
|
|
|
|
td->avg_buckets[rw][i].latency =
|
|
|
|
last_latency[rw];
|
|
|
|
continue;
|
|
|
|
}
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
if (!td->avg_buckets[rw][i].valid)
|
|
|
|
latency[rw] = avg_latency[rw][i].latency;
|
|
|
|
else
|
|
|
|
latency[rw] = (td->avg_buckets[rw][i].latency * 7 +
|
|
|
|
avg_latency[rw][i].latency) >> 3;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
td->avg_buckets[rw][i].latency = max(latency[rw],
|
|
|
|
last_latency[rw]);
|
|
|
|
td->avg_buckets[rw][i].valid = true;
|
|
|
|
last_latency[rw] = td->avg_buckets[rw][i].latency;
|
|
|
|
}
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
2017-05-18 04:07:25 +08:00
|
|
|
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++)
|
|
|
|
throtl_log(&td->service_queue,
|
2017-11-21 09:38:30 +08:00
|
|
|
"Latency bucket %d: read latency=%ld, read valid=%d, "
|
|
|
|
"write latency=%ld, write valid=%d", i,
|
|
|
|
td->avg_buckets[READ][i].latency,
|
|
|
|
td->avg_buckets[READ][i].valid,
|
|
|
|
td->avg_buckets[WRITE][i].latency,
|
|
|
|
td->avg_buckets[WRITE][i].valid);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void throtl_update_latency_buckets(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
}
|
2022-09-03 14:28:26 +08:00
|
|
|
|
|
|
|
static void blk_throtl_update_idletime(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void throtl_downgrade_check(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void throtl_upgrade_check(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_can_upgrade(struct throtl_data *td,
|
|
|
|
struct throtl_grp *this_tg)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void throtl_upgrade_state(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
}
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
#endif
|
|
|
|
|
2021-10-05 23:11:56 +08:00
|
|
|
bool __blk_throtl_bio(struct bio *bio)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2021-10-14 22:03:30 +08:00
|
|
|
struct request_queue *q = bdev_get_queue(bio->bi_bdev);
|
2020-06-27 15:31:58 +08:00
|
|
|
struct blkcg_gq *blkg = bio->bi_blkg;
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
struct throtl_qnode *qn = NULL;
|
2020-06-27 15:31:59 +08:00
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg);
|
2013-05-15 04:52:35 +08:00
|
|
|
struct throtl_service_queue *sq;
|
2013-05-15 04:52:35 +08:00
|
|
|
bool rw = bio_data_dir(bio);
|
2011-10-19 20:33:01 +08:00
|
|
|
bool throttled = false;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
struct throtl_data *td = tg->td;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2020-06-27 15:31:57 +08:00
|
|
|
rcu_read_lock();
|
2015-08-19 05:55:20 +08:00
|
|
|
|
2018-11-16 03:17:28 +08:00
|
|
|
spin_lock_irq(&q->queue_lock);
|
2015-08-19 05:55:19 +08:00
|
|
|
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
throtl_update_latency_buckets(td);
|
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
blk_throtl_update_idletime(tg);
|
|
|
|
|
2013-05-15 04:52:35 +08:00
|
|
|
sq = &tg->service_queue;
|
|
|
|
|
2017-03-28 01:51:34 +08:00
|
|
|
again:
|
2013-05-15 04:52:38 +08:00
|
|
|
while (true) {
|
2017-03-28 01:51:35 +08:00
|
|
|
if (tg->last_low_overflow_time[rw] == 0)
|
|
|
|
tg->last_low_overflow_time[rw] = jiffies;
|
|
|
|
throtl_downgrade_check(tg);
|
2017-03-28 01:51:43 +08:00
|
|
|
throtl_upgrade_check(tg);
|
2013-05-15 04:52:38 +08:00
|
|
|
/* throtl is FIFO - if bios are already queued, should queue */
|
|
|
|
if (sq->nr_queued[rw])
|
|
|
|
break;
|
2011-03-08 04:09:32 +08:00
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
/* if above limits, break to queue */
|
2017-03-28 01:51:34 +08:00
|
|
|
if (!tg_may_dispatch(tg, bio, NULL)) {
|
2017-03-28 01:51:35 +08:00
|
|
|
tg->last_low_overflow_time[rw] = jiffies;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
if (throtl_can_upgrade(td, tg)) {
|
|
|
|
throtl_upgrade_state(td);
|
2017-03-28 01:51:34 +08:00
|
|
|
goto again;
|
|
|
|
}
|
2013-05-15 04:52:38 +08:00
|
|
|
break;
|
2017-03-28 01:51:34 +08:00
|
|
|
}
|
2013-05-15 04:52:38 +08:00
|
|
|
|
|
|
|
/* within limits, let's charge and dispatch directly */
|
2010-09-16 05:06:35 +08:00
|
|
|
throtl_charge_bio(tg, bio);
|
2011-03-23 04:54:29 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to trim slice even when bios are not being queued
|
|
|
|
* otherwise it might happen that a bio is not queued for
|
|
|
|
* a long time and slice keeps on extending and trim is not
|
|
|
|
* called for a long time. Now if limits are reduced suddenly
|
|
|
|
* we take into account all the IO dispatched so far at new
|
|
|
|
* low rate and * newly queued IO gets a really long dispatch
|
|
|
|
* time.
|
|
|
|
*
|
|
|
|
* So keep on trimming slice even if bio is not queued.
|
|
|
|
*/
|
2013-05-15 04:52:32 +08:00
|
|
|
throtl_trim_slice(tg, rw);
|
2013-05-15 04:52:38 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* @bio passed through this layer without being throttled.
|
2020-09-07 16:10:13 +08:00
|
|
|
* Climb up the ladder. If we're already at the top, it
|
2013-05-15 04:52:38 +08:00
|
|
|
* can be executed directly.
|
|
|
|
*/
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
qn = &tg->qnode_on_parent[rw];
|
2013-05-15 04:52:38 +08:00
|
|
|
sq = sq->parent_sq;
|
|
|
|
tg = sq_to_tg(sq);
|
blk-throttle: fix that io throttle can only work for single bio
Test scripts:
cd /sys/fs/cgroup/blkio/
echo "8:0 1024" > blkio.throttle.write_bps_device
echo $$ > cgroup.procs
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
Test result:
10240 bytes (10 kB, 10 KiB) copied, 10.0134 s, 1.0 kB/s
10240 bytes (10 kB, 10 KiB) copied, 10.0135 s, 1.0 kB/s
The problem is that the second bio is finished after 10s instead of 20s.
Root cause:
1) second bio will be flagged:
__blk_throtl_bio
while (true) {
...
if (sq->nr_queued[rw]) -> some bio is throttled already
break
};
bio_set_flag(bio, BIO_THROTTLED); -> flag the bio
2) flagged bio will be dispatched without waiting:
throtl_dispatch_tg
tg_may_dispatch
tg_with_in_bps_limit
if (bps_limit == U64_MAX || bio_flagged(bio, BIO_THROTTLED))
*wait = 0; -> wait time is zero
return true;
commit 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
support to count split bios for iops limit, thus it adds flagged bio
checking in tg_with_in_bps_limit() so that split bios will only count
once for bps limit, however, it introduce a new problem that io throttle
won't work if multiple bios are throttled.
In order to fix the problem, handle iops/bps limit in different ways:
1) for iops limit, there is no flag to record if the bio is throttled,
and iops is always applied.
2) for bps limit, original bio will be flagged with BIO_BPS_THROTTLED,
and io throttle will ignore bio with the flag.
Noted this patch also remove the code to set flag in __bio_clone(), it's
introduced in commit 111be8839817 ("block-throttle: avoid double
charge"), and author thinks split bio can be resubmited and throttled
again, which is wrong because split bio will continue to dispatch from
caller.
Fixes: 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20220829022240.3348319-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-29 10:22:37 +08:00
|
|
|
if (!tg) {
|
|
|
|
bio_set_flag(bio, BIO_BPS_THROTTLED);
|
2013-05-15 04:52:38 +08:00
|
|
|
goto out_unlock;
|
blk-throttle: fix that io throttle can only work for single bio
Test scripts:
cd /sys/fs/cgroup/blkio/
echo "8:0 1024" > blkio.throttle.write_bps_device
echo $$ > cgroup.procs
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct &
Test result:
10240 bytes (10 kB, 10 KiB) copied, 10.0134 s, 1.0 kB/s
10240 bytes (10 kB, 10 KiB) copied, 10.0135 s, 1.0 kB/s
The problem is that the second bio is finished after 10s instead of 20s.
Root cause:
1) second bio will be flagged:
__blk_throtl_bio
while (true) {
...
if (sq->nr_queued[rw]) -> some bio is throttled already
break
};
bio_set_flag(bio, BIO_THROTTLED); -> flag the bio
2) flagged bio will be dispatched without waiting:
throtl_dispatch_tg
tg_may_dispatch
tg_with_in_bps_limit
if (bps_limit == U64_MAX || bio_flagged(bio, BIO_THROTTLED))
*wait = 0; -> wait time is zero
return true;
commit 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
support to count split bios for iops limit, thus it adds flagged bio
checking in tg_with_in_bps_limit() so that split bios will only count
once for bps limit, however, it introduce a new problem that io throttle
won't work if multiple bios are throttled.
In order to fix the problem, handle iops/bps limit in different ways:
1) for iops limit, there is no flag to record if the bio is throttled,
and iops is always applied.
2) for bps limit, original bio will be flagged with BIO_BPS_THROTTLED,
and io throttle will ignore bio with the flag.
Noted this patch also remove the code to set flag in __bio_clone(), it's
introduced in commit 111be8839817 ("block-throttle: avoid double
charge"), and author thinks split bio can be resubmited and throttled
again, which is wrong because split bio will continue to dispatch from
caller.
Fixes: 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20220829022240.3348319-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-29 10:22:37 +08:00
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 04:52:38 +08:00
|
|
|
/* out-of-limit, queue to @tg */
|
2013-05-15 04:52:36 +08:00
|
|
|
throtl_log(sq, "[%c] bio. bdisp=%llu sz=%u bps=%llu iodisp=%u iops=%u queued=%d/%d",
|
|
|
|
rw == READ ? 'R' : 'W',
|
2017-03-28 01:51:30 +08:00
|
|
|
tg->bytes_disp[rw], bio->bi_iter.bi_size,
|
|
|
|
tg_bps_limit(tg, rw),
|
|
|
|
tg->io_disp[rw], tg_iops_limit(tg, rw),
|
2013-05-15 04:52:36 +08:00
|
|
|
sq->nr_queued[READ], sq->nr_queued[WRITE]);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2017-03-28 01:51:35 +08:00
|
|
|
tg->last_low_overflow_time[rw] = jiffies;
|
|
|
|
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
td->nr_queued[rw]++;
|
blk-throttle: add throtl_qnode for dispatch fairness
With flat hierarchy, there's only single level of dispatching
happening and fairness beyond that point is the responsibility of the
rest of the block layer and driver, which usually works out okay;
however, with the planned hierarchy support,
service_queue->bio_lists[] can be filled up by bios from a single
source. While the limits would still be honored, it'd be very easy to
starve IOs from siblings or children.
To avoid such starvation, this patch implements throtl_qnode and
converts service_queue->bio_lists[] to lists of per-source qnodes
which in turn contains the bio's. For example, when a bio is
dispatched from a child group, the bio doesn't get queued on
->bio_lists[] directly but it first gets queued on the group's qnode
which in turn gets queued on service_queue->queued[]. When
dispatching for the upper level, the ->queued[] list is consumed in
round-robing order so that the dispatch windows is consumed fairly by
all IO sources.
There are two ways a bio can come to a throtl_grp - directly queued to
the group or dispatched from a child. For the former
throtl_grp->qnode_on_self[rw] is used. For the latter, the child's
->qnode_on_parent[rw].
Note that this means that the child which is contributing a bio to its
parent should stay pinned until all its bios are dispatched to its
grand-parent. This patch moves blkg refcnting from bio add/remove
spots to qnode activation/deactivation so that the blkg containing an
active qnode is always pinned. As child pins the parent, this is
sufficient for keeping the relevant sub-tree pinned while bios are in
flight.
The starvation issue was spotted by Vivek Goyal.
v2: The original patch used the same throtl_grp->qnode_on_self/parent
for reads and writes causing RWs to be queued incorrectly if there
already are outstanding IOs in the other direction. They should
be throtl_grp->qnode_on_self/parent[2] so that READs and WRITEs
can use different qnodes. Spotted by Vivek Goyal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-05-15 04:52:38 +08:00
|
|
|
throtl_add_bio_tg(bio, qn, tg);
|
2011-10-19 20:33:01 +08:00
|
|
|
throttled = true;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:37 +08:00
|
|
|
/*
|
|
|
|
* Update @tg's dispatch time and force schedule dispatch if @tg
|
|
|
|
* was empty before @bio. The forced scheduling isn't likely to
|
|
|
|
* cause undue delay as @bio is likely to be dispatched directly if
|
|
|
|
* its @tg's disptime is not in the future.
|
|
|
|
*/
|
2013-05-15 04:52:35 +08:00
|
|
|
if (tg->flags & THROTL_TG_WAS_EMPTY) {
|
2013-05-15 04:52:36 +08:00
|
|
|
tg_update_disptime(tg);
|
2013-05-15 04:52:37 +08:00
|
|
|
throtl_schedule_next_dispatch(tg->service_queue.parent_sq, true);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2011-10-19 20:33:01 +08:00
|
|
|
out_unlock:
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
if (throttled || !td->track_bio_latency)
|
2018-05-09 17:08:49 +08:00
|
|
|
bio->bi_issue.value |= BIO_ISSUE_THROTL_SKIP_LATENCY;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
#endif
|
2022-03-01 20:39:19 +08:00
|
|
|
spin_unlock_irq(&q->queue_lock);
|
|
|
|
|
2020-06-27 15:31:57 +08:00
|
|
|
rcu_read_unlock();
|
2011-10-19 20:33:01 +08:00
|
|
|
return throttled;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
static void throtl_track_latency(struct throtl_data *td, sector_t size,
|
2022-07-15 02:06:28 +08:00
|
|
|
enum req_op op, unsigned long time)
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
{
|
2022-07-15 02:06:28 +08:00
|
|
|
const bool rw = op_is_write(op);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
struct latency_bucket *latency;
|
|
|
|
int index;
|
|
|
|
|
2017-11-21 09:38:30 +08:00
|
|
|
if (!td || td->limit_index != LIMIT_LOW ||
|
|
|
|
!(op == REQ_OP_READ || op == REQ_OP_WRITE) ||
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
!blk_queue_nonrot(td->queue))
|
|
|
|
return;
|
|
|
|
|
|
|
|
index = request_bucket_index(size);
|
|
|
|
|
2022-07-15 02:06:28 +08:00
|
|
|
latency = get_cpu_ptr(td->latency_buckets[rw]);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
latency[index].total_latency += time;
|
|
|
|
latency[index].samples++;
|
2022-07-15 02:06:28 +08:00
|
|
|
put_cpu_ptr(td->latency_buckets[rw]);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void blk_throtl_stat_add(struct request *rq, u64 time_ns)
|
|
|
|
{
|
|
|
|
struct request_queue *q = rq->q;
|
|
|
|
struct throtl_data *td = q->td;
|
|
|
|
|
2019-05-21 15:59:03 +08:00
|
|
|
throtl_track_latency(td, blk_rq_stats_sectors(rq), req_op(rq),
|
|
|
|
time_ns >> 10);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
void blk_throtl_bio_endio(struct bio *bio)
|
|
|
|
{
|
2018-07-03 23:14:50 +08:00
|
|
|
struct blkcg_gq *blkg;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
struct throtl_grp *tg;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
u64 finish_time_ns;
|
|
|
|
unsigned long finish_time;
|
|
|
|
unsigned long start_time;
|
|
|
|
unsigned long lat;
|
2017-11-21 09:38:30 +08:00
|
|
|
int rw = bio_data_dir(bio);
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
|
2018-07-03 23:14:50 +08:00
|
|
|
blkg = bio->bi_blkg;
|
|
|
|
if (!blkg)
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
return;
|
2018-07-03 23:14:50 +08:00
|
|
|
tg = blkg_to_tg(blkg);
|
2020-10-08 11:52:24 +08:00
|
|
|
if (!tg->td->limit_valid[LIMIT_LOW])
|
|
|
|
return;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
finish_time_ns = ktime_get_ns();
|
|
|
|
tg->last_finish_time = finish_time_ns >> 10;
|
|
|
|
|
2018-05-09 17:08:49 +08:00
|
|
|
start_time = bio_issue_time(&bio->bi_issue) >> 10;
|
|
|
|
finish_time = __bio_issue_time(finish_time_ns) >> 10;
|
2018-07-03 23:14:50 +08:00
|
|
|
if (!start_time || finish_time <= start_time)
|
2017-03-28 06:19:43 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
lat = finish_time - start_time;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
/* this is only for bio based driver */
|
2018-05-09 17:08:49 +08:00
|
|
|
if (!(bio->bi_issue.value & BIO_ISSUE_THROTL_SKIP_LATENCY))
|
|
|
|
throtl_track_latency(tg->td, bio_issue_size(&bio->bi_issue),
|
|
|
|
bio_op(bio), lat);
|
2017-03-28 06:19:43 +08:00
|
|
|
|
2017-06-07 03:40:43 +08:00
|
|
|
if (tg->latency_target && lat >= tg->td->filtered_latency) {
|
2017-03-28 06:19:43 +08:00
|
|
|
int bucket;
|
|
|
|
unsigned int threshold;
|
|
|
|
|
2018-05-09 17:08:49 +08:00
|
|
|
bucket = request_bucket_index(bio_issue_size(&bio->bi_issue));
|
2017-11-21 09:38:30 +08:00
|
|
|
threshold = tg->td->avg_buckets[rw][bucket].latency +
|
2017-03-28 06:19:43 +08:00
|
|
|
tg->latency_target;
|
|
|
|
if (lat > threshold)
|
|
|
|
tg->bad_bio_cnt++;
|
|
|
|
/*
|
|
|
|
* Not race free, could get wrong count, which means cgroups
|
|
|
|
* will be throttled
|
|
|
|
*/
|
|
|
|
tg->bio_cnt++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (time_after(jiffies, tg->bio_cnt_reset_time) || tg->bio_cnt > 1024) {
|
|
|
|
tg->bio_cnt_reset_time = tg->td->throtl_slice + jiffies;
|
|
|
|
tg->bio_cnt /= 2;
|
|
|
|
tg->bad_bio_cnt /= 2;
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2022-09-22 02:04:56 +08:00
|
|
|
int blk_throtl_init(struct gendisk *disk)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2022-09-22 02:04:56 +08:00
|
|
|
struct request_queue *q = disk->queue;
|
2010-09-16 05:06:35 +08:00
|
|
|
struct throtl_data *td;
|
2012-04-14 04:11:33 +08:00
|
|
|
int ret;
|
2010-09-16 05:06:35 +08:00
|
|
|
|
|
|
|
td = kzalloc_node(sizeof(*td), GFP_KERNEL, q->node);
|
|
|
|
if (!td)
|
|
|
|
return -ENOMEM;
|
2017-11-21 09:38:30 +08:00
|
|
|
td->latency_buckets[READ] = __alloc_percpu(sizeof(struct latency_bucket) *
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
LATENCY_BUCKET_SIZE, __alignof__(u64));
|
2017-11-21 09:38:30 +08:00
|
|
|
if (!td->latency_buckets[READ]) {
|
|
|
|
kfree(td);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
td->latency_buckets[WRITE] = __alloc_percpu(sizeof(struct latency_bucket) *
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
LATENCY_BUCKET_SIZE, __alignof__(u64));
|
2017-11-21 09:38:30 +08:00
|
|
|
if (!td->latency_buckets[WRITE]) {
|
|
|
|
free_percpu(td->latency_buckets[READ]);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
kfree(td);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2013-05-15 04:52:36 +08:00
|
|
|
INIT_WORK(&td->dispatch_work, blk_throtl_dispatch_work_fn);
|
2015-08-19 05:55:13 +08:00
|
|
|
throtl_service_queue_init(&td->service_queue);
|
2010-09-16 05:06:35 +08:00
|
|
|
|
2012-03-06 05:15:06 +08:00
|
|
|
q->td = td;
|
2011-05-20 03:38:24 +08:00
|
|
|
td->queue = q;
|
2010-10-01 20:49:48 +08:00
|
|
|
|
2017-03-28 01:51:30 +08:00
|
|
|
td->limit_valid[LIMIT_MAX] = true;
|
2017-03-28 01:51:32 +08:00
|
|
|
td->limit_index = LIMIT_MAX;
|
2017-03-28 01:51:35 +08:00
|
|
|
td->low_upgrade_time = jiffies;
|
|
|
|
td->low_downgrade_time = jiffies;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
|
2012-04-14 04:11:33 +08:00
|
|
|
/* activate policy */
|
2023-02-03 23:03:57 +08:00
|
|
|
ret = blkcg_activate_policy(disk, &blkcg_policy_throtl);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
if (ret) {
|
2017-11-21 09:38:30 +08:00
|
|
|
free_percpu(td->latency_buckets[READ]);
|
|
|
|
free_percpu(td->latency_buckets[WRITE]);
|
2012-03-06 05:15:05 +08:00
|
|
|
kfree(td);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
}
|
2012-04-14 04:11:33 +08:00
|
|
|
return ret;
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2022-09-22 02:04:56 +08:00
|
|
|
void blk_throtl_exit(struct gendisk *disk)
|
2010-09-16 05:06:35 +08:00
|
|
|
{
|
2022-09-22 02:04:56 +08:00
|
|
|
struct request_queue *q = disk->queue;
|
|
|
|
|
2023-02-15 02:33:05 +08:00
|
|
|
BUG_ON(!q->td);
|
2021-09-07 20:12:42 +08:00
|
|
|
del_timer_sync(&q->td->service_queue.pending_timer);
|
2011-03-03 08:05:33 +08:00
|
|
|
throtl_shutdown_wq(q);
|
2023-02-03 23:03:57 +08:00
|
|
|
blkcg_deactivate_policy(disk, &blkcg_policy_throtl);
|
2017-11-21 09:38:30 +08:00
|
|
|
free_percpu(q->td->latency_buckets[READ]);
|
|
|
|
free_percpu(q->td->latency_buckets[WRITE]);
|
block: fix request_queue lifetime handling by making blk_queue_cleanup() properly shutdown
request_queue is refcounted but actually depdends on lifetime
management from the queue owner - on blk_cleanup_queue(), block layer
expects that there's no request passing through request_queue and no
new one will.
This is fundamentally broken. The queue owner (e.g. SCSI layer)
doesn't have a way to know whether there are other active users before
calling blk_cleanup_queue() and other users (e.g. bsg) don't have any
guarantee that the queue is and would stay valid while it's holding a
reference.
With delay added in blk_queue_bio() before queue_lock is grabbed, the
following oops can be easily triggered when a device is removed with
in-flight IOs.
sd 0:0:1:0: [sdb] Stopping disk
ata1.01: disabled
general protection fault: 0000 [#1] PREEMPT SMP
CPU 2
Modules linked in:
Pid: 648, comm: test_rawio Not tainted 3.1.0-rc3-work+ #56 Bochs Bochs
RIP: 0010:[<ffffffff8137d651>] [<ffffffff8137d651>] elv_rqhash_find+0x61/0x100
...
Process test_rawio (pid: 648, threadinfo ffff880019efa000, task ffff880019ef8a80)
...
Call Trace:
[<ffffffff8137d774>] elv_merge+0x84/0xe0
[<ffffffff81385b54>] blk_queue_bio+0xf4/0x400
[<ffffffff813838ea>] generic_make_request+0xca/0x100
[<ffffffff81383994>] submit_bio+0x74/0x100
[<ffffffff811c53ec>] dio_bio_submit+0xbc/0xc0
[<ffffffff811c610e>] __blockdev_direct_IO+0x92e/0xb40
[<ffffffff811c39f7>] blkdev_direct_IO+0x57/0x60
[<ffffffff8113b1c5>] generic_file_aio_read+0x6d5/0x760
[<ffffffff8118c1ca>] do_sync_read+0xda/0x120
[<ffffffff8118ce55>] vfs_read+0xc5/0x180
[<ffffffff8118cfaa>] sys_pread64+0x9a/0xb0
[<ffffffff81afaf6b>] system_call_fastpath+0x16/0x1b
This happens because blk_queue_cleanup() destroys the queue and
elevator whether IOs are in progress or not and DEAD tests are
sprinkled in the request processing path without proper
synchronization.
Similar problem exists for blk-throtl. On queue cleanup, blk-throtl
is shutdown whether it has requests in it or not. Depending on
timing, it either oopses or throttled bios are lost putting tasks
which are waiting for bio completion into eternal D state.
The way it should work is having the usual clear distinction between
shutdown and release. Shutdown drains all currently pending requests,
marks the queue dead, and performs partial teardown of the now
unnecessary part of the queue. Even after shutdown is complete,
reference holders are still allowed to issue requests to the queue
although they will be immmediately failed. The rest of teardown
happens on release.
This patch makes the following changes to make blk_queue_cleanup()
behave as proper shutdown.
* QUEUE_FLAG_DEAD is now set while holding both q->exit_mutex and
queue_lock.
* Unsynchronized DEAD check in generic_make_request_checks() removed.
This couldn't make any meaningful difference as the queue could die
after the check.
* blk_drain_queue() updated such that it can drain all requests and is
now called during cleanup.
* blk_throtl updated such that it checks DEAD on grabbing queue_lock,
drains all throttled bios during cleanup and free td when queue is
released.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2011-10-19 20:42:16 +08:00
|
|
|
kfree(q->td);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
2022-09-22 02:04:57 +08:00
|
|
|
void blk_throtl_register(struct gendisk *disk)
|
2017-03-28 01:51:38 +08:00
|
|
|
{
|
2022-09-22 02:04:57 +08:00
|
|
|
struct request_queue *q = disk->queue;
|
2017-03-28 01:51:38 +08:00
|
|
|
struct throtl_data *td;
|
2017-06-07 03:40:43 +08:00
|
|
|
int i;
|
2017-03-28 01:51:38 +08:00
|
|
|
|
|
|
|
td = q->td;
|
|
|
|
BUG_ON(!td);
|
|
|
|
|
2017-06-07 03:40:43 +08:00
|
|
|
if (blk_queue_nonrot(q)) {
|
2017-03-28 01:51:38 +08:00
|
|
|
td->throtl_slice = DFL_THROTL_SLICE_SSD;
|
2017-06-07 03:40:43 +08:00
|
|
|
td->filtered_latency = LATENCY_FILTERED_SSD;
|
|
|
|
} else {
|
2017-03-28 01:51:38 +08:00
|
|
|
td->throtl_slice = DFL_THROTL_SLICE_HD;
|
2017-06-07 03:40:43 +08:00
|
|
|
td->filtered_latency = LATENCY_FILTERED_HD;
|
2017-11-21 09:38:30 +08:00
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++) {
|
|
|
|
td->avg_buckets[READ][i].latency = DFL_HD_BASELINE_LATENCY;
|
|
|
|
td->avg_buckets[WRITE][i].latency = DFL_HD_BASELINE_LATENCY;
|
|
|
|
}
|
2017-06-07 03:40:43 +08:00
|
|
|
}
|
2017-03-28 01:51:38 +08:00
|
|
|
#ifndef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
/* if no low limit, use previous default */
|
|
|
|
td->throtl_slice = DFL_THROTL_SLICE_HD;
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 01:51:41 +08:00
|
|
|
|
2023-04-13 14:28:05 +08:00
|
|
|
#else
|
2018-11-16 03:22:51 +08:00
|
|
|
td->track_bio_latency = !queue_is_mq(q);
|
blk-throttle: add a mechanism to estimate IO latency
User configures latency target, but the latency threshold for each
request size isn't fixed. For a SSD, the IO latency highly depends on
request size. To calculate latency threshold, we sample some data, eg,
average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency
threshold of each request size will be the sample latency (I'll call it
base latency) plus latency target. For example, the base latency for
request size 4k is 80us and user configures latency target 60us. The 4k
latency threshold will be 80 + 60 = 140us.
To sample data, we calculate the order base 2 of rounded up IO sectors.
If the IO size is bigger than 1M, it will be accounted as 1M. Since the
calculation does round up, the base latency will be slightly smaller
than actual value. Also if there isn't any IO dispatched for a specific
IO size, we will use the base latency of smaller IO size for this IO
size.
But we shouldn't sample data at any time. The base latency is supposed
to be latency where disk isn't congested, because we use latency
threshold to schedule IOs between cgroups. If disk is congested, the
latency is higher, using it for scheduling is meaningless. Hence we only
do the sampling when block throttling is in the LOW limit, with
assumption disk isn't congested in such state. If the assumption isn't
true, eg, low limit is too high, calculated latency threshold will be
higher.
Hard disk is completely different. Latency depends on spindle seek
instead of request size. Currently this feature is SSD only, we probably
can use a fixed threshold like 4ms for hard disk though.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-28 06:19:42 +08:00
|
|
|
if (!td->track_bio_latency)
|
|
|
|
blk_stat_enable_accounting(q);
|
2023-04-13 14:28:05 +08:00
|
|
|
#endif
|
2017-03-28 01:51:38 +08:00
|
|
|
}
|
|
|
|
|
2017-03-28 01:51:37 +08:00
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
ssize_t blk_throtl_sample_time_show(struct request_queue *q, char *page)
|
|
|
|
{
|
|
|
|
if (!q->td)
|
|
|
|
return -EINVAL;
|
|
|
|
return sprintf(page, "%u\n", jiffies_to_msecs(q->td->throtl_slice));
|
|
|
|
}
|
|
|
|
|
|
|
|
ssize_t blk_throtl_sample_time_store(struct request_queue *q,
|
|
|
|
const char *page, size_t count)
|
|
|
|
{
|
|
|
|
unsigned long v;
|
|
|
|
unsigned long t;
|
|
|
|
|
|
|
|
if (!q->td)
|
|
|
|
return -EINVAL;
|
|
|
|
if (kstrtoul(page, 10, &v))
|
|
|
|
return -EINVAL;
|
|
|
|
t = msecs_to_jiffies(v);
|
|
|
|
if (t == 0 || t > MAX_THROTL_SLICE)
|
|
|
|
return -EINVAL;
|
|
|
|
q->td->throtl_slice = t;
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-09-16 05:06:35 +08:00
|
|
|
static int __init throtl_init(void)
|
|
|
|
{
|
2011-03-02 02:40:54 +08:00
|
|
|
kthrotld_workqueue = alloc_workqueue("kthrotld", WQ_MEM_RECLAIM, 0);
|
|
|
|
if (!kthrotld_workqueue)
|
|
|
|
panic("Failed to create kthrotld\n");
|
|
|
|
|
2012-04-17 04:57:25 +08:00
|
|
|
return blkcg_policy_register(&blkcg_policy_throtl);
|
2010-09-16 05:06:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
module_init(throtl_init);
|