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 08:07:57 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2010-09-15 15:06:35 -06: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>
|
2015-05-22 15:13:17 -06:00
|
|
|
#include <linux/blk-cgroup.h>
|
2011-10-19 06:31:18 -06:00
|
|
|
#include "blk.h"
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
/* Max dispatch from a group in 1 round */
|
|
|
|
static int throtl_grp_quantum = 8;
|
|
|
|
|
|
|
|
/* Total max dispatch from all groups in one round */
|
|
|
|
static int throtl_quantum = 32;
|
|
|
|
|
2017-03-27 11:51:38 -06: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-27 11:51:37 -06: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-27 11:51:41 -06:00
|
|
|
#define MAX_IDLE_TIME (5L * 1000 * 1000) /* 5 s */
|
2017-05-17 14:07:26 -06:00
|
|
|
#define MIN_THROTL_BPS (320 * 1024)
|
|
|
|
#define MIN_THROTL_IOPS (10)
|
2017-05-17 14:07:27 -06:00
|
|
|
#define DFL_LATENCY_TARGET (-1L)
|
|
|
|
#define DFL_IDLE_THRESHOLD (0)
|
2017-06-06 13:40:43 -06: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-15 15:06:35 -06: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-27 16:19:42 -06:00
|
|
|
#define SKIP_LATENCY (((u64)1) << BLK_STAT_RES_SHIFT)
|
|
|
|
|
2012-04-16 14:57:25 -06:00
|
|
|
static struct blkcg_policy blkcg_policy_throtl;
|
2012-03-05 14:15:14 -07:00
|
|
|
|
2011-03-01 11:40:54 -07:00
|
|
|
/* A workqueue to queue throttle related work */
|
|
|
|
static struct workqueue_struct *kthrotld_workqueue;
|
|
|
|
|
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-14 14:52:38 -06:00
|
|
|
/*
|
|
|
|
* To implement hierarchical throttling, throtl_grps form a tree and bios
|
|
|
|
* are dispatched upwards level by level until they reach the top and get
|
|
|
|
* issued. When dispatching bios from the children and local group at each
|
|
|
|
* level, if the bios are dispatched into a single bio_list, there's a risk
|
|
|
|
* of a local or child group which can queue many bios at once filling up
|
|
|
|
* the list starving others.
|
|
|
|
*
|
|
|
|
* To avoid such starvation, dispatched bios are queued separately
|
|
|
|
* according to where they came from. When they are again dispatched to
|
|
|
|
* the parent, they're popped in round-robin order so that no single source
|
|
|
|
* hogs the dispatch window.
|
|
|
|
*
|
|
|
|
* throtl_qnode is used to keep the queued bios separated by their sources.
|
|
|
|
* Bios are queued to throtl_qnode which in turn is queued to
|
|
|
|
* throtl_service_queue and then dispatched in round-robin order.
|
|
|
|
*
|
|
|
|
* It's also used to track the reference counts on blkg's. A qnode always
|
|
|
|
* belongs to a throtl_grp and gets queued on itself or the parent, so
|
|
|
|
* incrementing the reference of the associated throtl_grp when a qnode is
|
|
|
|
* queued and decrementing when dequeued is enough to keep the whole blkg
|
|
|
|
* tree pinned while bios are in flight.
|
|
|
|
*/
|
|
|
|
struct throtl_qnode {
|
|
|
|
struct list_head node; /* service_queue->queued[] */
|
|
|
|
struct bio_list bios; /* queued bios */
|
|
|
|
struct throtl_grp *tg; /* tg this qnode belongs to */
|
|
|
|
};
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
struct throtl_service_queue {
|
2013-05-14 14:52:36 -06:00
|
|
|
struct throtl_service_queue *parent_sq; /* the parent service_queue */
|
|
|
|
|
2013-05-14 14:52:35 -06:00
|
|
|
/*
|
|
|
|
* Bios queued directly to this service_queue or dispatched from
|
|
|
|
* children throtl_grp's.
|
|
|
|
*/
|
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-14 14:52:38 -06:00
|
|
|
struct list_head queued[2]; /* throtl_qnode [READ/WRITE] */
|
2013-05-14 14:52:35 -06:00
|
|
|
unsigned int nr_queued[2]; /* number of queued bios */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RB tree of active children throtl_grp's, which are sorted by
|
|
|
|
* their ->disptime.
|
|
|
|
*/
|
2013-05-14 14:52:32 -06:00
|
|
|
struct rb_root pending_tree; /* RB tree of active tgs */
|
|
|
|
struct rb_node *first_pending; /* first node in the tree */
|
|
|
|
unsigned int nr_pending; /* # queued in the tree */
|
|
|
|
unsigned long first_pending_disptime; /* disptime of the first tg */
|
2013-05-14 14:52:36 -06:00
|
|
|
struct timer_list pending_timer; /* fires on first_pending_disptime */
|
2010-09-15 15:06:35 -06:00
|
|
|
};
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
enum tg_state_flags {
|
|
|
|
THROTL_TG_PENDING = 1 << 0, /* on parent's pending tree */
|
2013-05-14 14:52:35 -06:00
|
|
|
THROTL_TG_WAS_EMPTY = 1 << 1, /* bio_lists[] became non-empty */
|
2013-05-14 14:52:32 -06:00
|
|
|
};
|
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
#define rb_entry_tg(node) rb_entry((node), struct throtl_grp, rb_node)
|
|
|
|
|
2017-03-27 11:51:30 -06:00
|
|
|
enum {
|
2017-03-27 11:51:32 -06:00
|
|
|
LIMIT_LOW,
|
2017-03-27 11:51:30 -06:00
|
|
|
LIMIT_MAX,
|
|
|
|
LIMIT_CNT,
|
|
|
|
};
|
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
struct throtl_grp {
|
2012-04-16 14:57:26 -06:00
|
|
|
/* must be the first member */
|
|
|
|
struct blkg_policy_data pd;
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
/* active throtl group service_queue member */
|
2010-09-15 15:06:35 -06:00
|
|
|
struct rb_node rb_node;
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
/* throtl_data this group belongs to */
|
|
|
|
struct throtl_data *td;
|
|
|
|
|
2013-05-14 14:52:34 -06:00
|
|
|
/* this group's service queue */
|
|
|
|
struct throtl_service_queue service_queue;
|
|
|
|
|
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-14 14:52:38 -06:00
|
|
|
/*
|
|
|
|
* qnode_on_self is used when bios are directly queued to this
|
|
|
|
* throtl_grp so that local bios compete fairly with bios
|
|
|
|
* dispatched from children. qnode_on_parent is used when bios are
|
|
|
|
* dispatched from this throtl_grp into its parent and will compete
|
|
|
|
* with the sibling qnode_on_parents and the parent's
|
|
|
|
* qnode_on_self.
|
|
|
|
*/
|
|
|
|
struct throtl_qnode qnode_on_self[2];
|
|
|
|
struct throtl_qnode qnode_on_parent[2];
|
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
/*
|
|
|
|
* Dispatch time in jiffies. This is the estimated time when group
|
|
|
|
* will unthrottle and is ready to dispatch more bio. It is used as
|
|
|
|
* key to sort active groups in service tree.
|
|
|
|
*/
|
|
|
|
unsigned long disptime;
|
|
|
|
|
|
|
|
unsigned int flags;
|
|
|
|
|
2013-05-14 14:52:38 -06:00
|
|
|
/* are there any throtl rules between this group and td? */
|
|
|
|
bool has_rules[2];
|
|
|
|
|
2017-03-27 11:51:32 -06:00
|
|
|
/* internally used bytes per second rate limits */
|
2017-03-27 11:51:30 -06:00
|
|
|
uint64_t bps[2][LIMIT_CNT];
|
2017-03-27 11:51:32 -06:00
|
|
|
/* user configured bps limits */
|
|
|
|
uint64_t bps_conf[2][LIMIT_CNT];
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-03-27 11:51:32 -06:00
|
|
|
/* internally used IOPS limits */
|
2017-03-27 11:51:30 -06:00
|
|
|
unsigned int iops[2][LIMIT_CNT];
|
2017-03-27 11:51:32 -06:00
|
|
|
/* user configured IOPS limits */
|
|
|
|
unsigned int iops_conf[2][LIMIT_CNT];
|
2010-09-15 15:06:37 -06:00
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
/* Number of bytes disptached in current slice */
|
|
|
|
uint64_t bytes_disp[2];
|
2010-09-15 15:06:37 -06:00
|
|
|
/* Number of bio's dispatched in current slice */
|
|
|
|
unsigned int io_disp[2];
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-03-27 11:51:35 -06:00
|
|
|
unsigned long last_low_overflow_time[2];
|
|
|
|
|
|
|
|
uint64_t last_bytes_disp[2];
|
|
|
|
unsigned int last_io_disp[2];
|
|
|
|
|
|
|
|
unsigned long last_check_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-27 11:51:44 -06:00
|
|
|
unsigned long latency_target; /* us */
|
2017-05-17 14:07:24 -06:00
|
|
|
unsigned long latency_target_conf; /* us */
|
2010-09-15 15:06:35 -06:00
|
|
|
/* When did we start a new slice */
|
|
|
|
unsigned long slice_start[2];
|
|
|
|
unsigned long slice_end[2];
|
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-27 11:51:41 -06:00
|
|
|
|
|
|
|
unsigned long last_finish_time; /* ns / 1024 */
|
|
|
|
unsigned long checked_last_finish_time; /* ns / 1024 */
|
|
|
|
unsigned long avg_idletime; /* ns / 1024 */
|
|
|
|
unsigned long idletime_threshold; /* us */
|
2017-05-17 14:07:24 -06:00
|
|
|
unsigned long idletime_threshold_conf; /* us */
|
2017-03-27 16:19:43 -06:00
|
|
|
|
|
|
|
unsigned int bio_cnt; /* total bios */
|
|
|
|
unsigned int bad_bio_cnt; /* bios exceeding latency threshold */
|
|
|
|
unsigned long bio_cnt_reset_time;
|
2010-09-15 15:06:35 -06: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-27 16:19:42 -06: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-15 15:06:35 -06:00
|
|
|
struct throtl_data
|
|
|
|
{
|
|
|
|
/* service tree for active throtl groups */
|
2013-05-14 14:52:32 -06:00
|
|
|
struct throtl_service_queue service_queue;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
struct request_queue *queue;
|
|
|
|
|
|
|
|
/* Total Number of queued bios on READ and WRITE lists */
|
|
|
|
unsigned int nr_queued[2];
|
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
unsigned int throtl_slice;
|
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
/* Work for dispatching throttled bios */
|
2013-05-14 14:52:36 -06:00
|
|
|
struct work_struct dispatch_work;
|
2017-03-27 11:51:30 -06:00
|
|
|
unsigned int limit_index;
|
|
|
|
bool limit_valid[LIMIT_CNT];
|
2017-03-27 11:51:35 -06: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-27 11:51:40 -06: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-27 16:19:42 -06:00
|
|
|
|
|
|
|
struct latency_bucket tmp_buckets[LATENCY_BUCKET_SIZE];
|
|
|
|
struct avg_latency_bucket avg_buckets[LATENCY_BUCKET_SIZE];
|
|
|
|
struct latency_bucket __percpu *latency_buckets;
|
|
|
|
unsigned long last_calculate_time;
|
2017-06-06 13:40:43 -06: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-27 16:19:42 -06:00
|
|
|
|
|
|
|
bool track_bio_latency;
|
2010-09-15 15:06:35 -06:00
|
|
|
};
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void throtl_pending_timer_fn(unsigned long arg);
|
|
|
|
|
2012-04-16 14:57:26 -06:00
|
|
|
static inline struct throtl_grp *pd_to_tg(struct blkg_policy_data *pd)
|
|
|
|
{
|
|
|
|
return pd ? container_of(pd, struct throtl_grp, pd) : NULL;
|
|
|
|
}
|
|
|
|
|
2012-04-16 14:57:25 -06:00
|
|
|
static inline struct throtl_grp *blkg_to_tg(struct blkcg_gq *blkg)
|
2012-03-05 14:15:14 -07:00
|
|
|
{
|
2012-04-16 14:57:26 -06:00
|
|
|
return pd_to_tg(blkg_to_pd(blkg, &blkcg_policy_throtl));
|
2012-03-05 14:15:14 -07:00
|
|
|
}
|
|
|
|
|
2012-04-16 14:57:25 -06:00
|
|
|
static inline struct blkcg_gq *tg_to_blkg(struct throtl_grp *tg)
|
2012-03-05 14:15:14 -07:00
|
|
|
{
|
2012-04-16 14:57:26 -06:00
|
|
|
return pd_to_blkg(&tg->pd);
|
2012-03-05 14:15:14 -07:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06: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-27 15:29:09 -07:00
|
|
|
* A service_queue can be embedded in either a throtl_grp or throtl_data.
|
2013-05-14 14:52:36 -06: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-27 11:51:40 -06:00
|
|
|
/*
|
|
|
|
* cgroup's limit in LIMIT_MAX is scaled if low limit is set. This scale is to
|
|
|
|
* make the IO dispatch more smooth.
|
|
|
|
* Scale up: linearly scale up according to lapsed time since upgrade. For
|
|
|
|
* 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-27 11:51:30 -06:00
|
|
|
static uint64_t tg_bps_limit(struct throtl_grp *tg, int rw)
|
|
|
|
{
|
2017-03-27 11:51:33 -06: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-27 11:51:40 -06:00
|
|
|
struct throtl_data *td;
|
2017-03-27 11:51:33 -06: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-27 11:51:40 -06:00
|
|
|
|
|
|
|
td = tg->td;
|
|
|
|
ret = tg->bps[rw][td->limit_index];
|
2017-05-17 14:07:26 -06: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-27 11:51:40 -06: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-27 11:51:33 -06:00
|
|
|
return ret;
|
2017-03-27 11:51:30 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int tg_iops_limit(struct throtl_grp *tg, int rw)
|
|
|
|
{
|
2017-03-27 11:51:33 -06: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-27 11:51:40 -06:00
|
|
|
struct throtl_data *td;
|
2017-03-27 11:51:33 -06:00
|
|
|
unsigned int ret;
|
|
|
|
|
|
|
|
if (cgroup_subsys_on_dfl(io_cgrp_subsys) && !blkg->parent)
|
|
|
|
return UINT_MAX;
|
2017-05-17 14:07:26 -06: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-27 11:51:40 -06:00
|
|
|
td = tg->td;
|
|
|
|
ret = tg->iops[rw][td->limit_index];
|
2017-05-17 14:07:26 -06: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-27 11:51:40 -06: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-27 11:51:33 -06:00
|
|
|
return ret;
|
2017-03-27 11:51:30 -06: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-27 16:19:42 -06:00
|
|
|
#define request_bucket_index(sectors) \
|
|
|
|
clamp_t(int, order_base_2(sectors) - 3, 0, LATENCY_BUCKET_SIZE - 1)
|
|
|
|
|
2013-05-14 14:52:36 -06: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-09 18:22:15 -06:00
|
|
|
if (likely(!blk_trace_note_message_enabled(__td->queue))) \
|
|
|
|
break; \
|
2013-05-14 14:52:36 -06:00
|
|
|
if ((__tg)) { \
|
2017-07-12 12:49:56 -06:00
|
|
|
blk_add_cgroup_trace_msg(__td->queue, \
|
|
|
|
tg_to_blkg(__tg)->blkcg, "throtl " fmt, ##args);\
|
2013-05-14 14:52:36 -06:00
|
|
|
} else { \
|
|
|
|
blk_add_trace_msg(__td->queue, "throtl " fmt, ##args); \
|
|
|
|
} \
|
2012-04-16 14:57:23 -06:00
|
|
|
} while (0)
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-08-18 17:08:13 -06: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-14 14:52:38 -06: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)
|
|
|
|
{
|
|
|
|
struct throtl_qnode *qn = list_first_entry(queued, struct throtl_qnode, node);
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
if (list_empty(queued))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
struct throtl_qnode *qn = list_first_entry(queued, struct throtl_qnode, node);
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
if (list_empty(queued))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
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-14 14:52:34 -06:00
|
|
|
/* init a service_queue, assumes the caller zeroed it */
|
2015-08-18 15:55:13 -06:00
|
|
|
static void throtl_service_queue_init(struct throtl_service_queue *sq)
|
2013-05-14 14:52:34 -06: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-14 14:52:38 -06:00
|
|
|
INIT_LIST_HEAD(&sq->queued[0]);
|
|
|
|
INIT_LIST_HEAD(&sq->queued[1]);
|
2013-05-14 14:52:34 -06:00
|
|
|
sq->pending_tree = RB_ROOT;
|
2013-05-14 14:52:36 -06:00
|
|
|
setup_timer(&sq->pending_timer, throtl_pending_timer_fn,
|
|
|
|
(unsigned long)sq);
|
|
|
|
}
|
|
|
|
|
2015-08-18 15:55:11 -06:00
|
|
|
static struct blkg_policy_data *throtl_pd_alloc(gfp_t gfp, int node)
|
|
|
|
{
|
2015-08-18 15:55:12 -06:00
|
|
|
struct throtl_grp *tg;
|
2015-08-18 15:55:22 -06:00
|
|
|
int rw;
|
2015-08-18 15:55:12 -06:00
|
|
|
|
|
|
|
tg = kzalloc_node(sizeof(*tg), gfp, node);
|
|
|
|
if (!tg)
|
2015-08-18 15:55:24 -06:00
|
|
|
return NULL;
|
2015-08-18 15:55:12 -06:00
|
|
|
|
2015-08-18 15:55:13 -06: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-27 11:51:30 -06: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-27 11:51:32 -06: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-18 15:55:13 -06: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-27 11:51:44 -06:00
|
|
|
tg->latency_target = DFL_LATENCY_TARGET;
|
2017-05-17 14:07:24 -06:00
|
|
|
tg->latency_target_conf = DFL_LATENCY_TARGET;
|
2017-05-17 14:07:27 -06: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-27 11:51:44 -06:00
|
|
|
|
2015-08-18 15:55:12 -06:00
|
|
|
return &tg->pd;
|
2015-08-18 15:55:11 -06:00
|
|
|
}
|
|
|
|
|
2015-08-18 15:55:14 -06:00
|
|
|
static void throtl_pd_init(struct blkg_policy_data *pd)
|
2011-05-19 13:38:19 -06:00
|
|
|
{
|
2015-08-18 15:55:14 -06:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
struct blkcg_gq *blkg = tg_to_blkg(tg);
|
2013-05-14 14:52:36 -06:00
|
|
|
struct throtl_data *td = blkg->q->td;
|
2015-08-18 15:55:13 -06:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2012-03-05 14:15:06 -07:00
|
|
|
|
2013-05-14 14:52:38 -06:00
|
|
|
/*
|
2014-07-09 08:08:08 -06:00
|
|
|
* If on the default hierarchy, we switch to properly hierarchical
|
2013-05-14 14:52:38 -06: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
|
|
|
|
* read_bps limit is set on the root group, the whole system can't
|
|
|
|
* exceed 16M for the device.
|
|
|
|
*
|
2014-07-09 08:08:08 -06:00
|
|
|
* If not on the default hierarchy, the broken flat hierarchy
|
2013-05-14 14:52:38 -06: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-18 15:55:13 -06:00
|
|
|
sq->parent_sq = &td->service_queue;
|
2015-09-18 09:56:28 -06:00
|
|
|
if (cgroup_subsys_on_dfl(io_cgrp_subsys) && blkg->parent)
|
2015-08-18 15:55:13 -06:00
|
|
|
sq->parent_sq = &blkg_to_tg(blkg->parent)->service_queue;
|
2013-05-14 14:52:36 -06:00
|
|
|
tg->td = td;
|
2012-04-01 15:38:44 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:38 -06: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-27 11:51:30 -06:00
|
|
|
struct throtl_data *td = tg->td;
|
2013-05-14 14:52:38 -06:00
|
|
|
int rw;
|
|
|
|
|
|
|
|
for (rw = READ; rw <= WRITE; rw++)
|
|
|
|
tg->has_rules[rw] = (parent_tg && parent_tg->has_rules[rw]) ||
|
2017-03-27 11:51:30 -06:00
|
|
|
(td->limit_valid[td->limit_index] &&
|
|
|
|
(tg_bps_limit(tg, rw) != U64_MAX ||
|
|
|
|
tg_iops_limit(tg, rw) != UINT_MAX));
|
2013-05-14 14:52:38 -06:00
|
|
|
}
|
|
|
|
|
2015-08-18 15:55:14 -06:00
|
|
|
static void throtl_pd_online(struct blkg_policy_data *pd)
|
2013-05-14 14:52:38 -06:00
|
|
|
{
|
2017-03-27 11:51:39 -06:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
2013-05-14 14:52:38 -06: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-27 11:51:39 -06:00
|
|
|
tg_update_has_rules(tg);
|
2013-05-14 14:52:38 -06:00
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:32 -06: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();
|
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg) {
|
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg);
|
|
|
|
|
|
|
|
if (tg->bps[READ][LIMIT_LOW] || tg->bps[WRITE][LIMIT_LOW] ||
|
|
|
|
tg->iops[READ][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW])
|
|
|
|
low_valid = true;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
td->limit_valid[LIMIT_LOW] = low_valid;
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:34 -06:00
|
|
|
static void throtl_upgrade_state(struct throtl_data *td);
|
2017-03-27 11:51:32 -06: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-27 11:51:34 -06:00
|
|
|
if (!tg->td->limit_valid[tg->td->limit_index])
|
|
|
|
throtl_upgrade_state(tg->td);
|
2017-03-27 11:51:32 -06:00
|
|
|
}
|
|
|
|
|
2015-08-18 15:55:11 -06:00
|
|
|
static void throtl_pd_free(struct blkg_policy_data *pd)
|
|
|
|
{
|
2015-08-18 15:55:12 -06:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
|
2015-08-18 15:55:13 -06:00
|
|
|
del_timer_sync(&tg->service_queue.pending_timer);
|
2015-08-18 15:55:12 -06:00
|
|
|
kfree(tg);
|
2015-08-18 15:55:11 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
static struct throtl_grp *
|
|
|
|
throtl_rb_first(struct throtl_service_queue *parent_sq)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
/* Service tree is empty */
|
2013-05-14 14:52:33 -06:00
|
|
|
if (!parent_sq->nr_pending)
|
2010-09-15 15:06:35 -06:00
|
|
|
return NULL;
|
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
if (!parent_sq->first_pending)
|
|
|
|
parent_sq->first_pending = rb_first(&parent_sq->pending_tree);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
if (parent_sq->first_pending)
|
|
|
|
return rb_entry_tg(parent_sq->first_pending);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rb_erase_init(struct rb_node *n, struct rb_root *root)
|
|
|
|
{
|
|
|
|
rb_erase(n, root);
|
|
|
|
RB_CLEAR_NODE(n);
|
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
static void throtl_rb_erase(struct rb_node *n,
|
|
|
|
struct throtl_service_queue *parent_sq)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:33 -06:00
|
|
|
if (parent_sq->first_pending == n)
|
|
|
|
parent_sq->first_pending = NULL;
|
|
|
|
rb_erase_init(n, &parent_sq->pending_tree);
|
|
|
|
--parent_sq->nr_pending;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
static void update_min_dispatch_time(struct throtl_service_queue *parent_sq)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
struct throtl_grp *tg;
|
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
tg = throtl_rb_first(parent_sq);
|
2010-09-15 15:06:35 -06:00
|
|
|
if (!tg)
|
|
|
|
return;
|
|
|
|
|
2013-05-14 14:52:33 -06:00
|
|
|
parent_sq->first_pending_disptime = tg->disptime;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void tg_service_queue_add(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:36 -06:00
|
|
|
struct throtl_service_queue *parent_sq = tg->service_queue.parent_sq;
|
2013-05-14 14:52:33 -06:00
|
|
|
struct rb_node **node = &parent_sq->pending_tree.rb_node;
|
2010-09-15 15:06:35 -06:00
|
|
|
struct rb_node *parent = NULL;
|
|
|
|
struct throtl_grp *__tg;
|
|
|
|
unsigned long key = tg->disptime;
|
|
|
|
int left = 1;
|
|
|
|
|
|
|
|
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;
|
|
|
|
left = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (left)
|
2013-05-14 14:52:33 -06:00
|
|
|
parent_sq->first_pending = &tg->rb_node;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
rb_link_node(&tg->rb_node, parent, node);
|
2013-05-14 14:52:33 -06:00
|
|
|
rb_insert_color(&tg->rb_node, &parent_sq->pending_tree);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void __throtl_enqueue_tg(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:36 -06:00
|
|
|
tg_service_queue_add(tg);
|
2013-05-14 14:52:32 -06:00
|
|
|
tg->flags |= THROTL_TG_PENDING;
|
2013-05-14 14:52:36 -06:00
|
|
|
tg->service_queue.parent_sq->nr_pending++;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void throtl_enqueue_tg(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:32 -06:00
|
|
|
if (!(tg->flags & THROTL_TG_PENDING))
|
2013-05-14 14:52:36 -06:00
|
|
|
__throtl_enqueue_tg(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void __throtl_dequeue_tg(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_rb_erase(&tg->rb_node, tg->service_queue.parent_sq);
|
2013-05-14 14:52:32 -06:00
|
|
|
tg->flags &= ~THROTL_TG_PENDING;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void throtl_dequeue_tg(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:32 -06:00
|
|
|
if (tg->flags & THROTL_TG_PENDING)
|
2013-05-14 14:52:36 -06:00
|
|
|
__throtl_dequeue_tg(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:31 -06:00
|
|
|
/* Call with queue lock held */
|
2013-05-14 14:52:36 -06:00
|
|
|
static void throtl_schedule_pending_timer(struct throtl_service_queue *sq,
|
|
|
|
unsigned long expires)
|
2013-05-14 14:52:31 -06:00
|
|
|
{
|
2017-06-06 21:36:14 -06:00
|
|
|
unsigned long max_expire = jiffies + 8 * sq_to_td(sq)->throtl_slice;
|
2017-03-27 11:51:36 -06: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-14 14:52:36 -06:00
|
|
|
mod_timer(&sq->pending_timer, expires);
|
|
|
|
throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu",
|
|
|
|
expires - jiffies, jiffies);
|
2013-05-14 14:52:31 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:37 -06: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-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:32 -06:00
|
|
|
/* any pending children left? */
|
2013-05-14 14:52:32 -06:00
|
|
|
if (!sq->nr_pending)
|
2013-05-14 14:52:37 -06:00
|
|
|
return true;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
update_min_dispatch_time(sq);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
/* is the next dispatch time in the future? */
|
2013-05-14 14:52:37 -06:00
|
|
|
if (force || time_after(sq->first_pending_disptime, jiffies)) {
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_schedule_pending_timer(sq, sq->first_pending_disptime);
|
2013-05-14 14:52:37 -06:00
|
|
|
return true;
|
2013-05-14 14:52:36 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/* tell the caller to continue dispatching */
|
|
|
|
return false;
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06: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;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
if (time_after_eq(start, tg->slice_start[rw]))
|
|
|
|
tg->slice_start[rw] = start;
|
|
|
|
|
2017-03-27 11:51:37 -06: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-14 14:52:38 -06: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);
|
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
static inline void throtl_start_new_slice(struct throtl_grp *tg, bool rw)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
tg->bytes_disp[rw] = 0;
|
2010-09-15 15:06:37 -06:00
|
|
|
tg->io_disp[rw] = 0;
|
2010-09-15 15:06:35 -06:00
|
|
|
tg->slice_start[rw] = jiffies;
|
2017-03-27 11:51:37 -06:00
|
|
|
tg->slice_end[rw] = jiffies + tg->td->throtl_slice;
|
2013-05-14 14:52:36 -06: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-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
static inline void throtl_set_slice_end(struct throtl_grp *tg, bool rw,
|
|
|
|
unsigned long jiffy_end)
|
2010-12-01 11:34:46 -07:00
|
|
|
{
|
2017-03-27 11:51:37 -06:00
|
|
|
tg->slice_end[rw] = roundup(jiffy_end, tg->td->throtl_slice);
|
2010-12-01 11:34:46 -07:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
static inline void throtl_extend_slice(struct throtl_grp *tg, bool rw,
|
|
|
|
unsigned long jiffy_end)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2017-03-27 11:51:37 -06:00
|
|
|
tg->slice_end[rw] = roundup(jiffy_end, tg->td->throtl_slice);
|
2013-05-14 14:52:36 -06: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-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Determine if previously allocated or extended slice is complete or not */
|
2013-05-14 14:52:32 -06:00
|
|
|
static bool throtl_slice_used(struct throtl_grp *tg, bool rw)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
if (time_in_range(jiffies, tg->slice_start[rw], tg->slice_end[rw]))
|
2014-05-02 10:28:17 -06:00
|
|
|
return false;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Trim the used slices and adjust slice start accordingly */
|
2013-05-14 14:52:32 -06:00
|
|
|
static inline void throtl_trim_slice(struct throtl_grp *tg, bool rw)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2010-10-01 06:51:14 -06:00
|
|
|
unsigned long nr_slices, time_elapsed, io_trim;
|
|
|
|
u64 bytes_trim, tmp;
|
2010-09-15 15:06:35 -06: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-14 14:52:32 -06:00
|
|
|
if (throtl_slice_used(tg, rw))
|
2010-09-15 15:06:35 -06:00
|
|
|
return;
|
|
|
|
|
2010-12-01 11:34:46 -07:00
|
|
|
/*
|
|
|
|
* A bio has been dispatched. Also adjust slice_end. It might happen
|
|
|
|
* that initially cgroup limit was very low resulting in high
|
|
|
|
* slice_end, but later limit was bumped up and bio was dispached
|
|
|
|
* 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-27 11:51:37 -06:00
|
|
|
throtl_set_slice_end(tg, rw, jiffies + tg->td->throtl_slice);
|
2010-12-01 11:34:46 -07:00
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
time_elapsed = jiffies - tg->slice_start[rw];
|
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
nr_slices = time_elapsed / tg->td->throtl_slice;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
if (!nr_slices)
|
|
|
|
return;
|
2017-03-27 11:51:37 -06:00
|
|
|
tmp = tg_bps_limit(tg, rw) * tg->td->throtl_slice * nr_slices;
|
2010-10-01 06:51:14 -06:00
|
|
|
do_div(tmp, HZ);
|
|
|
|
bytes_trim = tmp;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
io_trim = (tg_iops_limit(tg, rw) * tg->td->throtl_slice * nr_slices) /
|
|
|
|
HZ;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2010-09-15 15:06:37 -06:00
|
|
|
if (!bytes_trim && !io_trim)
|
2010-09-15 15:06:35 -06:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (tg->bytes_disp[rw] >= bytes_trim)
|
|
|
|
tg->bytes_disp[rw] -= bytes_trim;
|
|
|
|
else
|
|
|
|
tg->bytes_disp[rw] = 0;
|
|
|
|
|
2010-09-15 15:06:37 -06:00
|
|
|
if (tg->io_disp[rw] >= io_trim)
|
|
|
|
tg->io_disp[rw] -= io_trim;
|
|
|
|
else
|
|
|
|
tg->io_disp[rw] = 0;
|
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
tg->slice_start[rw] += nr_slices * tg->td->throtl_slice;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"[%c] trim slice nr=%lu bytes=%llu io=%lu start=%lu end=%lu jiffies=%lu",
|
|
|
|
rw == READ ? 'R' : 'W', nr_slices, bytes_trim, io_trim,
|
|
|
|
tg->slice_start[rw], tg->slice_end[rw], jiffies);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
static bool tg_with_in_iops_limit(struct throtl_grp *tg, struct bio *bio,
|
|
|
|
unsigned long *wait)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
2010-09-15 15:06:37 -06:00
|
|
|
unsigned int io_allowed;
|
2010-09-15 15:06:35 -06:00
|
|
|
unsigned long jiffy_elapsed, jiffy_wait, jiffy_elapsed_rnd;
|
2010-10-01 13:16:42 -06:00
|
|
|
u64 tmp;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2010-09-15 15:06:37 -06:00
|
|
|
jiffy_elapsed = jiffy_elapsed_rnd = jiffies - tg->slice_start[rw];
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2010-09-15 15:06:37 -06:00
|
|
|
/* Slice has just started. Consider one slice interval */
|
|
|
|
if (!jiffy_elapsed)
|
2017-03-27 11:51:37 -06:00
|
|
|
jiffy_elapsed_rnd = tg->td->throtl_slice;
|
2010-09-15 15:06:37 -06:00
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
jiffy_elapsed_rnd = roundup(jiffy_elapsed_rnd, tg->td->throtl_slice);
|
2010-09-15 15:06:37 -06:00
|
|
|
|
2010-10-01 13:16:42 -06:00
|
|
|
/*
|
|
|
|
* jiffy_elapsed_rnd 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.
|
|
|
|
*/
|
|
|
|
|
2017-03-27 11:51:30 -06:00
|
|
|
tmp = (u64)tg_iops_limit(tg, rw) * jiffy_elapsed_rnd;
|
2010-10-01 13:16:42 -06:00
|
|
|
do_div(tmp, HZ);
|
|
|
|
|
|
|
|
if (tmp > UINT_MAX)
|
|
|
|
io_allowed = UINT_MAX;
|
|
|
|
else
|
|
|
|
io_allowed = tmp;
|
2010-09-15 15:06:37 -06:00
|
|
|
|
|
|
|
if (tg->io_disp[rw] + 1 <= io_allowed) {
|
2010-09-15 15:06:35 -06:00
|
|
|
if (wait)
|
|
|
|
*wait = 0;
|
2014-05-02 10:28:17 -06:00
|
|
|
return true;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2010-09-15 15:06:37 -06:00
|
|
|
/* Calc approx time to dispatch */
|
2017-03-27 11:51:30 -06:00
|
|
|
jiffy_wait = ((tg->io_disp[rw] + 1) * HZ) / tg_iops_limit(tg, rw) + 1;
|
2010-09-15 15:06:37 -06:00
|
|
|
|
|
|
|
if (jiffy_wait > jiffy_elapsed)
|
|
|
|
jiffy_wait = jiffy_wait - jiffy_elapsed;
|
|
|
|
else
|
|
|
|
jiffy_wait = 1;
|
|
|
|
|
|
|
|
if (wait)
|
|
|
|
*wait = jiffy_wait;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
static bool tg_with_in_bps_limit(struct throtl_grp *tg, struct bio *bio,
|
|
|
|
unsigned long *wait)
|
2010-09-15 15:06:37 -06:00
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
2010-10-01 06:51:14 -06:00
|
|
|
u64 bytes_allowed, extra_bytes, tmp;
|
2010-09-15 15:06:37 -06:00
|
|
|
unsigned long jiffy_elapsed, jiffy_wait, jiffy_elapsed_rnd;
|
2017-08-18 17:08:13 -06:00
|
|
|
unsigned int bio_size = throtl_bio_data_size(bio);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
jiffy_elapsed = jiffy_elapsed_rnd = jiffies - tg->slice_start[rw];
|
|
|
|
|
|
|
|
/* Slice has just started. Consider one slice interval */
|
|
|
|
if (!jiffy_elapsed)
|
2017-03-27 11:51:37 -06:00
|
|
|
jiffy_elapsed_rnd = tg->td->throtl_slice;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
jiffy_elapsed_rnd = roundup(jiffy_elapsed_rnd, tg->td->throtl_slice);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-03-27 11:51:30 -06:00
|
|
|
tmp = tg_bps_limit(tg, rw) * jiffy_elapsed_rnd;
|
2010-10-01 13:16:38 -06:00
|
|
|
do_div(tmp, HZ);
|
2010-10-01 06:51:14 -06:00
|
|
|
bytes_allowed = tmp;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-08-18 17:08:13 -06:00
|
|
|
if (tg->bytes_disp[rw] + bio_size <= bytes_allowed) {
|
2010-09-15 15:06:35 -06:00
|
|
|
if (wait)
|
|
|
|
*wait = 0;
|
2014-05-02 10:28:17 -06:00
|
|
|
return true;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Calc approx time to dispatch */
|
2017-08-18 17:08:13 -06:00
|
|
|
extra_bytes = tg->bytes_disp[rw] + bio_size - bytes_allowed;
|
2017-03-27 11:51:30 -06:00
|
|
|
jiffy_wait = div64_u64(extra_bytes * HZ, tg_bps_limit(tg, rw));
|
2010-09-15 15:06:35 -06: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);
|
|
|
|
if (wait)
|
|
|
|
*wait = jiffy_wait;
|
2010-09-15 15:06:37 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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-14 14:52:32 -06:00
|
|
|
static bool tg_may_dispatch(struct throtl_grp *tg, struct bio *bio,
|
|
|
|
unsigned long *wait)
|
2010-09-15 15:06:37 -06:00
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
|
|
|
unsigned long bps_wait = 0, iops_wait = 0, max_wait = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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-14 14:52:35 -06: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-14 14:52:38 -06:00
|
|
|
bio != throtl_peek_queued(&tg->service_queue.queued[rw]));
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2010-09-15 15:06:37 -06:00
|
|
|
/* If tg->bps = -1, then BW is unlimited */
|
2017-03-27 11:51:30 -06:00
|
|
|
if (tg_bps_limit(tg, rw) == U64_MAX &&
|
|
|
|
tg_iops_limit(tg, rw) == UINT_MAX) {
|
2010-09-15 15:06:37 -06:00
|
|
|
if (wait)
|
|
|
|
*wait = 0;
|
2014-05-02 10:28:17 -06:00
|
|
|
return true;
|
2010-09-15 15:06:37 -06: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-19 15:12:41 -06: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-15 15:06:37 -06:00
|
|
|
*/
|
2016-09-19 15:12:41 -06:00
|
|
|
if (throtl_slice_used(tg, rw) && !(tg->service_queue.nr_queued[rw]))
|
2013-05-14 14:52:32 -06:00
|
|
|
throtl_start_new_slice(tg, rw);
|
2010-09-15 15:06:37 -06:00
|
|
|
else {
|
2017-03-27 11:51:37 -06: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-15 15:06:37 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
if (tg_with_in_bps_limit(tg, bio, &bps_wait) &&
|
|
|
|
tg_with_in_iops_limit(tg, bio, &iops_wait)) {
|
2010-09-15 15:06:37 -06:00
|
|
|
if (wait)
|
|
|
|
*wait = 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
max_wait = max(bps_wait, iops_wait);
|
|
|
|
|
|
|
|
if (wait)
|
|
|
|
*wait = max_wait;
|
|
|
|
|
|
|
|
if (time_before(tg->slice_end[rw], jiffies + max_wait))
|
2013-05-14 14:52:32 -06:00
|
|
|
throtl_extend_slice(tg, rw, jiffies + max_wait);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void throtl_charge_bio(struct throtl_grp *tg, struct bio *bio)
|
|
|
|
{
|
|
|
|
bool rw = bio_data_dir(bio);
|
2017-08-18 17:08:13 -06:00
|
|
|
unsigned int bio_size = throtl_bio_data_size(bio);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
/* Charge the bio to the group */
|
2017-08-18 17:08:13 -06:00
|
|
|
tg->bytes_disp[rw] += bio_size;
|
2010-09-15 15:06:37 -06:00
|
|
|
tg->io_disp[rw]++;
|
2017-08-18 17:08:13 -06:00
|
|
|
tg->last_bytes_disp[rw] += bio_size;
|
2017-03-27 11:51:35 -06:00
|
|
|
tg->last_io_disp[rw]++;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
/*
|
2016-10-20 07:12:12 -06:00
|
|
|
* BIO_THROTTLED is used to prevent the same bio to be throttled
|
2013-05-14 14:52:36 -06:00
|
|
|
* more than once as a throttled bio will go through blk-throtl the
|
|
|
|
* second time when it eventually gets issued. Set it when a bio
|
|
|
|
* is being charged to a tg.
|
|
|
|
*/
|
2016-10-20 07:12:12 -06:00
|
|
|
if (!bio_flagged(bio, BIO_THROTTLED))
|
|
|
|
bio_set_flag(bio, BIO_THROTTLED);
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06: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-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:35 -06:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06:00
|
|
|
if (!qn)
|
|
|
|
qn = &tg->qnode_on_self[rw];
|
|
|
|
|
2013-05-14 14:52:35 -06: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
|
|
|
|
* cleaered on the next tg_update_disptime().
|
|
|
|
*/
|
|
|
|
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-14 14:52:38 -06:00
|
|
|
throtl_qnode_add_bio(bio, qn, &sq->queued[rw]);
|
|
|
|
|
2013-05-14 14:52:35 -06:00
|
|
|
sq->nr_queued[rw]++;
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_enqueue_tg(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static void tg_update_disptime(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:35 -06:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-15 15:06:35 -06:00
|
|
|
unsigned long read_wait = -1, write_wait = -1, min_wait = -1, disptime;
|
|
|
|
struct bio *bio;
|
|
|
|
|
2017-01-21 14:15:33 -07:00
|
|
|
bio = throtl_peek_queued(&sq->queued[READ]);
|
|
|
|
if (bio)
|
2013-05-14 14:52:32 -06:00
|
|
|
tg_may_dispatch(tg, bio, &read_wait);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-01-21 14:15:33 -07:00
|
|
|
bio = throtl_peek_queued(&sq->queued[WRITE]);
|
|
|
|
if (bio)
|
2013-05-14 14:52:32 -06:00
|
|
|
tg_may_dispatch(tg, bio, &write_wait);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
min_wait = min(read_wait, write_wait);
|
|
|
|
disptime = jiffies + min_wait;
|
|
|
|
|
|
|
|
/* Update dispatch time */
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_dequeue_tg(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
tg->disptime = disptime;
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_enqueue_tg(tg);
|
2013-05-14 14:52:35 -06:00
|
|
|
|
|
|
|
/* see throtl_add_bio_tg() */
|
|
|
|
tg->flags &= ~THROTL_TG_WAS_EMPTY;
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06: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-14 14:52:36 -06:00
|
|
|
static void tg_dispatch_one_bio(struct throtl_grp *tg, bool rw)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:35 -06:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2013-05-14 14:52:38 -06: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-14 14:52:38 -06:00
|
|
|
struct throtl_grp *tg_to_put = NULL;
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06: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-14 14:52:35 -06:00
|
|
|
sq->nr_queued[rw]--;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
throtl_charge_bio(tg, bio);
|
2013-05-14 14:52:38 -06: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-14 14:52:38 -06: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-14 14:52:38 -06:00
|
|
|
start_parent_slice_with_credit(tg, parent_tg, rw);
|
2013-05-14 14:52:38 -06:00
|
|
|
} else {
|
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-14 14:52:38 -06:00
|
|
|
throtl_qnode_add_bio(bio, &tg->qnode_on_parent[rw],
|
|
|
|
&parent_sq->queued[rw]);
|
2013-05-14 14:52:38 -06:00
|
|
|
BUG_ON(tg->td->nr_queued[rw] <= 0);
|
|
|
|
tg->td->nr_queued[rw]--;
|
|
|
|
}
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
throtl_trim_slice(tg, rw);
|
2013-05-14 14:52:38 -06: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-14 14:52:38 -06:00
|
|
|
if (tg_to_put)
|
|
|
|
blkg_put(tg_to_blkg(tg_to_put));
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
static int throtl_dispatch_tg(struct throtl_grp *tg)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2013-05-14 14:52:35 -06:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-15 15:06:35 -06:00
|
|
|
unsigned int nr_reads = 0, nr_writes = 0;
|
|
|
|
unsigned int max_nr_reads = throtl_grp_quantum*3/4;
|
2010-11-15 11:32:42 -07:00
|
|
|
unsigned int max_nr_writes = throtl_grp_quantum - max_nr_reads;
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06:00
|
|
|
while ((bio = throtl_peek_queued(&sq->queued[READ])) &&
|
2013-05-14 14:52:32 -06:00
|
|
|
tg_may_dispatch(tg, bio, NULL)) {
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
tg_dispatch_one_bio(tg, bio_data_dir(bio));
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06:00
|
|
|
while ((bio = throtl_peek_queued(&sq->queued[WRITE])) &&
|
2013-05-14 14:52:32 -06:00
|
|
|
tg_may_dispatch(tg, bio, NULL)) {
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
tg_dispatch_one_bio(tg, bio_data_dir(bio));
|
2010-09-15 15:06:35 -06:00
|
|
|
nr_writes++;
|
|
|
|
|
|
|
|
if (nr_writes >= max_nr_writes)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return nr_reads + nr_writes;
|
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:35 -06:00
|
|
|
static int throtl_select_dispatch(struct throtl_service_queue *parent_sq)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
unsigned int nr_disp = 0;
|
|
|
|
|
|
|
|
while (1) {
|
2013-05-14 14:52:35 -06:00
|
|
|
struct throtl_grp *tg = throtl_rb_first(parent_sq);
|
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
if (!tg)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (time_before(jiffies, tg->disptime))
|
|
|
|
break;
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_dequeue_tg(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
nr_disp += throtl_dispatch_tg(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:35 -06:00
|
|
|
if (sq->nr_queued[0] || sq->nr_queued[1])
|
2013-05-14 14:52:36 -06:00
|
|
|
tg_update_disptime(tg);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
if (nr_disp >= throtl_quantum)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return nr_disp;
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:34 -06:00
|
|
|
static bool throtl_can_upgrade(struct throtl_data *td,
|
|
|
|
struct throtl_grp *this_tg);
|
2013-05-14 14:52:37 -06:00
|
|
|
/**
|
|
|
|
* throtl_pending_timer_fn - timer function for service_queue->pending_timer
|
|
|
|
* @arg: the throtl_service_queue being serviced
|
|
|
|
*
|
|
|
|
* 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-14 14:52:38 -06: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-14 14:52:37 -06:00
|
|
|
*/
|
2013-05-14 14:52:36 -06:00
|
|
|
static void throtl_pending_timer_fn(unsigned long arg)
|
|
|
|
{
|
|
|
|
struct throtl_service_queue *sq = (void *)arg;
|
2013-05-14 14:52:38 -06:00
|
|
|
struct throtl_grp *tg = sq_to_tg(sq);
|
2013-05-14 14:52:36 -06:00
|
|
|
struct throtl_data *td = sq_to_td(sq);
|
2013-05-14 14:52:31 -06:00
|
|
|
struct request_queue *q = td->queue;
|
2013-05-14 14:52:38 -06:00
|
|
|
struct throtl_service_queue *parent_sq;
|
|
|
|
bool dispatched;
|
2013-05-14 14:52:37 -06:00
|
|
|
int ret;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
spin_lock_irq(q->queue_lock);
|
2017-03-27 11:51:34 -06:00
|
|
|
if (throtl_can_upgrade(td, NULL))
|
|
|
|
throtl_upgrade_state(td);
|
|
|
|
|
2013-05-14 14:52:38 -06:00
|
|
|
again:
|
|
|
|
parent_sq = sq->parent_sq;
|
|
|
|
dispatched = false;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
while (true) {
|
|
|
|
throtl_log(sq, "dispatch nr_queued=%u read=%u write=%u",
|
2013-05-14 14:52:38 -06:00
|
|
|
sq->nr_queued[READ] + sq->nr_queued[WRITE],
|
|
|
|
sq->nr_queued[READ], sq->nr_queued[WRITE]);
|
2013-05-14 14:52:37 -06:00
|
|
|
|
|
|
|
ret = throtl_select_dispatch(sq);
|
|
|
|
if (ret) {
|
|
|
|
throtl_log(sq, "bios disp=%u", ret);
|
|
|
|
dispatched = true;
|
|
|
|
}
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
if (throtl_schedule_next_dispatch(sq, false))
|
|
|
|
break;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/* this dispatch windows is still open, relax and repeat */
|
|
|
|
spin_unlock_irq(q->queue_lock);
|
|
|
|
cpu_relax();
|
|
|
|
spin_lock_irq(q->queue_lock);
|
2013-05-14 14:52:35 -06:00
|
|
|
}
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:38 -06:00
|
|
|
if (!dispatched)
|
|
|
|
goto out_unlock;
|
2013-05-14 14:52:37 -06:00
|
|
|
|
2013-05-14 14:52:38 -06: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 {
|
|
|
|
/* reached the top-level, queue issueing */
|
|
|
|
queue_work(kthrotld_workqueue, &td->dispatch_work);
|
|
|
|
}
|
|
|
|
out_unlock:
|
2010-09-15 15:06:35 -06:00
|
|
|
spin_unlock_irq(q->queue_lock);
|
2013-05-14 14:52:37 -06:00
|
|
|
}
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/**
|
|
|
|
* blk_throtl_dispatch_work_fn - work function for throtl_data->dispatch_work
|
|
|
|
* @work: work item being executed
|
|
|
|
*
|
|
|
|
* This function is queued for execution when bio's reach the bio_lists[]
|
|
|
|
* of throtl_data->service_queue. Those bio's are ready and issued by this
|
|
|
|
* function.
|
|
|
|
*/
|
2014-04-17 13:41:16 -06:00
|
|
|
static void blk_throtl_dispatch_work_fn(struct work_struct *work)
|
2013-05-14 14:52:37 -06: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);
|
|
|
|
|
|
|
|
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-14 14:52:38 -06: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);
|
2013-05-14 14:52:37 -06:00
|
|
|
spin_unlock_irq(q->queue_lock);
|
|
|
|
|
|
|
|
if (!bio_list_empty(&bio_list_on_stack)) {
|
2011-03-09 00:27:37 -07:00
|
|
|
blk_start_plug(&plug);
|
2010-09-15 15:06:35 -06:00
|
|
|
while((bio = bio_list_pop(&bio_list_on_stack)))
|
|
|
|
generic_make_request(bio);
|
2011-03-09 00:27:37 -07:00
|
|
|
blk_finish_plug(&plug);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-16 14:57:26 -06:00
|
|
|
static u64 tg_prfill_conf_u64(struct seq_file *sf, struct blkg_policy_data *pd,
|
|
|
|
int off)
|
2012-04-01 15:38:43 -06:00
|
|
|
{
|
2012-04-16 14:57:26 -06:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
u64 v = *(u64 *)((void *)tg + off);
|
2012-04-01 15:38:43 -06:00
|
|
|
|
2017-03-27 11:51:29 -06:00
|
|
|
if (v == U64_MAX)
|
2012-04-01 15:38:43 -06:00
|
|
|
return 0;
|
2012-04-16 14:57:26 -06:00
|
|
|
return __blkg_prfill_u64(sf, pd, v);
|
2012-04-01 15:38:43 -06:00
|
|
|
}
|
|
|
|
|
2012-04-16 14:57:26 -06:00
|
|
|
static u64 tg_prfill_conf_uint(struct seq_file *sf, struct blkg_policy_data *pd,
|
|
|
|
int off)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
2012-04-16 14:57:26 -06:00
|
|
|
struct throtl_grp *tg = pd_to_tg(pd);
|
|
|
|
unsigned int v = *(unsigned int *)((void *)tg + off);
|
2010-10-01 06:49:49 -06:00
|
|
|
|
2017-03-27 11:51:29 -06:00
|
|
|
if (v == UINT_MAX)
|
2012-04-01 15:38:44 -06:00
|
|
|
return 0;
|
2012-04-16 14:57:26 -06:00
|
|
|
return __blkg_prfill_u64(sf, pd, v);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-12-05 10:28:04 -07:00
|
|
|
static int tg_print_conf_u64(struct seq_file *sf, void *v)
|
2010-09-15 15:06:37 -06:00
|
|
|
{
|
2013-12-05 10:28:04 -07: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-01 15:38:44 -06:00
|
|
|
return 0;
|
2010-09-15 15:06:37 -06:00
|
|
|
}
|
|
|
|
|
2013-12-05 10:28:04 -07:00
|
|
|
static int tg_print_conf_uint(struct seq_file *sf, void *v)
|
2010-09-15 15:06:37 -06:00
|
|
|
{
|
2013-12-05 10:28:04 -07: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-01 15:38:44 -06:00
|
|
|
return 0;
|
2012-04-01 15:38:43 -06:00
|
|
|
}
|
|
|
|
|
2017-05-17 14:07:26 -06:00
|
|
|
static void tg_conf_updated(struct throtl_grp *tg, bool global)
|
2012-04-01 15:38:43 -06:00
|
|
|
{
|
2015-08-18 15:55:32 -06:00
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
2013-08-08 18:11:25 -06:00
|
|
|
struct cgroup_subsys_state *pos_css;
|
2015-08-18 15:55:32 -06:00
|
|
|
struct blkcg_gq *blkg;
|
2012-04-01 15:38:44 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
throtl_log(&tg->service_queue,
|
|
|
|
"limit change rbps=%llu wbps=%llu riops=%u wiops=%u",
|
2017-03-27 11:51:30 -06:00
|
|
|
tg_bps_limit(tg, READ), tg_bps_limit(tg, WRITE),
|
|
|
|
tg_iops_limit(tg, READ), tg_iops_limit(tg, WRITE));
|
2013-05-14 14:52:31 -06:00
|
|
|
|
2013-05-14 14:52:38 -06: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-17 14:07:26 -06:00
|
|
|
blkg_for_each_descendant_pre(blkg, pos_css,
|
|
|
|
global ? tg->td->queue->root_blkg : tg_to_blkg(tg)) {
|
2017-05-17 14:07:24 -06: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);
|
|
|
|
}
|
2013-05-14 14:52:38 -06:00
|
|
|
|
2013-05-14 14:52:31 -06: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.
|
|
|
|
*/
|
2013-05-14 14:52:32 -06:00
|
|
|
throtl_start_new_slice(tg, 0);
|
|
|
|
throtl_start_new_slice(tg, 1);
|
2013-05-14 14:52:31 -06:00
|
|
|
|
2013-05-14 14:52:32 -06:00
|
|
|
if (tg->flags & THROTL_TG_PENDING) {
|
2013-05-14 14:52:36 -06:00
|
|
|
tg_update_disptime(tg);
|
2013-05-14 14:52:37 -06:00
|
|
|
throtl_schedule_next_dispatch(sq->parent_sq, true);
|
2013-05-14 14:52:31 -06:00
|
|
|
}
|
2015-08-18 15:55:32 -06: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;
|
|
|
|
|
|
|
|
ret = blkg_conf_prep(blkcg, &blkcg_policy_throtl, buf, &ctx);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
if (sscanf(ctx.body, "%llu", &v) != 1)
|
|
|
|
goto out_finish;
|
|
|
|
if (!v)
|
2017-03-27 11:51:29 -06:00
|
|
|
v = U64_MAX;
|
2015-08-18 15:55:32 -06:00
|
|
|
|
|
|
|
tg = blkg_to_tg(ctx.blkg);
|
|
|
|
|
|
|
|
if (is_u64)
|
|
|
|
*(u64 *)((void *)tg + of_cft(of)->private) = v;
|
|
|
|
else
|
|
|
|
*(unsigned int *)((void *)tg + of_cft(of)->private) = v;
|
2012-04-01 15:38:43 -06:00
|
|
|
|
2017-05-17 14:07:26 -06:00
|
|
|
tg_conf_updated(tg, false);
|
2015-08-18 15:55:31 -06:00
|
|
|
ret = 0;
|
|
|
|
out_finish:
|
2012-04-01 15:38:43 -06:00
|
|
|
blkg_conf_finish(&ctx);
|
2015-08-18 15:55:31 -06:00
|
|
|
return ret ?: nbytes;
|
2010-09-15 15:06:37 -06:00
|
|
|
}
|
|
|
|
|
2014-05-13 10:16:21 -06:00
|
|
|
static ssize_t tg_set_conf_u64(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes, loff_t off)
|
2012-04-01 15:38:43 -06:00
|
|
|
{
|
2014-05-13 10:16:21 -06:00
|
|
|
return tg_set_conf(of, buf, nbytes, off, true);
|
2012-04-01 15:38:43 -06:00
|
|
|
}
|
|
|
|
|
2014-05-13 10:16:21 -06:00
|
|
|
static ssize_t tg_set_conf_uint(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes, loff_t off)
|
2012-04-01 15:38:43 -06:00
|
|
|
{
|
2014-05-13 10:16:21 -06:00
|
|
|
return tg_set_conf(of, buf, nbytes, off, false);
|
2012-04-01 15:38:43 -06:00
|
|
|
}
|
|
|
|
|
2015-08-18 15:55:30 -06:00
|
|
|
static struct cftype throtl_legacy_files[] = {
|
2012-04-01 15:38:43 -06:00
|
|
|
{
|
|
|
|
.name = "throttle.read_bps_device",
|
2017-03-27 11:51:30 -06:00
|
|
|
.private = offsetof(struct throtl_grp, bps[READ][LIMIT_MAX]),
|
2013-12-05 10:28:04 -07:00
|
|
|
.seq_show = tg_print_conf_u64,
|
2014-05-13 10:16:21 -06:00
|
|
|
.write = tg_set_conf_u64,
|
2012-04-01 15:38:43 -06:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.write_bps_device",
|
2017-03-27 11:51:30 -06:00
|
|
|
.private = offsetof(struct throtl_grp, bps[WRITE][LIMIT_MAX]),
|
2013-12-05 10:28:04 -07:00
|
|
|
.seq_show = tg_print_conf_u64,
|
2014-05-13 10:16:21 -06:00
|
|
|
.write = tg_set_conf_u64,
|
2012-04-01 15:38:43 -06:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.read_iops_device",
|
2017-03-27 11:51:30 -06:00
|
|
|
.private = offsetof(struct throtl_grp, iops[READ][LIMIT_MAX]),
|
2013-12-05 10:28:04 -07:00
|
|
|
.seq_show = tg_print_conf_uint,
|
2014-05-13 10:16:21 -06:00
|
|
|
.write = tg_set_conf_uint,
|
2012-04-01 15:38:43 -06:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.write_iops_device",
|
2017-03-27 11:51:30 -06:00
|
|
|
.private = offsetof(struct throtl_grp, iops[WRITE][LIMIT_MAX]),
|
2013-12-05 10:28:04 -07:00
|
|
|
.seq_show = tg_print_conf_uint,
|
2014-05-13 10:16:21 -06:00
|
|
|
.write = tg_set_conf_uint,
|
2012-04-01 15:38:43 -06:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.io_service_bytes",
|
2015-08-18 15:55:24 -06:00
|
|
|
.private = (unsigned long)&blkcg_policy_throtl,
|
|
|
|
.seq_show = blkg_print_stat_bytes,
|
2012-04-01 15:38:43 -06:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "throttle.io_serviced",
|
2015-08-18 15:55:24 -06:00
|
|
|
.private = (unsigned long)&blkcg_policy_throtl,
|
|
|
|
.seq_show = blkg_print_stat_ios,
|
2012-04-01 15:38:43 -06:00
|
|
|
},
|
|
|
|
{ } /* terminate */
|
|
|
|
};
|
|
|
|
|
2017-03-27 11:51:32 -06:00
|
|
|
static u64 tg_prfill_limit(struct seq_file *sf, struct blkg_policy_data *pd,
|
2015-08-18 15:55:34 -06: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-27 11:51:32 -06:00
|
|
|
u64 bps_dft;
|
|
|
|
unsigned int iops_dft;
|
2017-03-27 11:51:42 -06: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-27 11:51:44 -06:00
|
|
|
char latency_time[26] = "";
|
2015-08-18 15:55:34 -06:00
|
|
|
|
|
|
|
if (!dname)
|
|
|
|
return 0;
|
2017-03-27 11:51:30 -06:00
|
|
|
|
2017-03-27 11:51:32 -06: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-27 11:51:42 -06: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-27 11:51:44 -06:00
|
|
|
(off != LIMIT_LOW ||
|
2017-05-17 14:07:27 -06:00
|
|
|
(tg->idletime_threshold_conf == DFL_IDLE_THRESHOLD &&
|
2017-05-17 14:07:24 -06:00
|
|
|
tg->latency_target_conf == DFL_LATENCY_TARGET)))
|
2015-08-18 15:55:34 -06:00
|
|
|
return 0;
|
|
|
|
|
2017-05-17 14:07:26 -06:00
|
|
|
if (tg->bps_conf[READ][off] != U64_MAX)
|
2017-03-27 11:51:30 -06:00
|
|
|
snprintf(bufs[0], sizeof(bufs[0]), "%llu",
|
2017-03-27 11:51:32 -06:00
|
|
|
tg->bps_conf[READ][off]);
|
2017-05-17 14:07:26 -06:00
|
|
|
if (tg->bps_conf[WRITE][off] != U64_MAX)
|
2017-03-27 11:51:30 -06:00
|
|
|
snprintf(bufs[1], sizeof(bufs[1]), "%llu",
|
2017-03-27 11:51:32 -06:00
|
|
|
tg->bps_conf[WRITE][off]);
|
2017-05-17 14:07:26 -06:00
|
|
|
if (tg->iops_conf[READ][off] != UINT_MAX)
|
2017-03-27 11:51:30 -06:00
|
|
|
snprintf(bufs[2], sizeof(bufs[2]), "%u",
|
2017-03-27 11:51:32 -06:00
|
|
|
tg->iops_conf[READ][off]);
|
2017-05-17 14:07:26 -06:00
|
|
|
if (tg->iops_conf[WRITE][off] != UINT_MAX)
|
2017-03-27 11:51:30 -06:00
|
|
|
snprintf(bufs[3], sizeof(bufs[3]), "%u",
|
2017-03-27 11:51:32 -06:00
|
|
|
tg->iops_conf[WRITE][off]);
|
2017-03-27 11:51:42 -06:00
|
|
|
if (off == LIMIT_LOW) {
|
2017-05-17 14:07:24 -06:00
|
|
|
if (tg->idletime_threshold_conf == ULONG_MAX)
|
2017-03-27 11:51:42 -06:00
|
|
|
strcpy(idle_time, " idle=max");
|
|
|
|
else
|
|
|
|
snprintf(idle_time, sizeof(idle_time), " idle=%lu",
|
2017-05-17 14:07:24 -06: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-27 11:51:44 -06:00
|
|
|
|
2017-05-17 14:07:24 -06: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-27 11:51:44 -06:00
|
|
|
strcpy(latency_time, " latency=max");
|
|
|
|
else
|
|
|
|
snprintf(latency_time, sizeof(latency_time),
|
2017-05-17 14:07:24 -06:00
|
|
|
" latency=%lu", tg->latency_target_conf);
|
2017-03-27 11:51:42 -06:00
|
|
|
}
|
2015-08-18 15:55:34 -06: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-27 11:51:44 -06: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-18 15:55:34 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:32 -06:00
|
|
|
static int tg_print_limit(struct seq_file *sf, void *v)
|
2015-08-18 15:55:34 -06:00
|
|
|
{
|
2017-03-27 11:51:32 -06:00
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), tg_prfill_limit,
|
2015-08-18 15:55:34 -06:00
|
|
|
&blkcg_policy_throtl, seq_cft(sf)->private, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:32 -06:00
|
|
|
static ssize_t tg_set_limit(struct kernfs_open_file *of,
|
2015-08-18 15:55:34 -06: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-27 11:51:42 -06: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-27 11:51:44 -06:00
|
|
|
unsigned long latency_time;
|
2015-08-18 15:55:34 -06:00
|
|
|
int ret;
|
2017-03-27 11:51:32 -06:00
|
|
|
int index = of_cft(of)->private;
|
2015-08-18 15:55:34 -06:00
|
|
|
|
|
|
|
ret = blkg_conf_prep(blkcg, &blkcg_policy_throtl, buf, &ctx);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
tg = blkg_to_tg(ctx.blkg);
|
|
|
|
|
2017-03-27 11:51:32 -06: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-18 15:55:34 -06:00
|
|
|
|
2017-05-17 14:07:24 -06:00
|
|
|
idle_time = tg->idletime_threshold_conf;
|
|
|
|
latency_time = tg->latency_target_conf;
|
2015-08-18 15:55:34 -06:00
|
|
|
while (true) {
|
|
|
|
char tok[27]; /* wiops=18446744073709551616 */
|
|
|
|
char *p;
|
2017-03-27 11:51:29 -06:00
|
|
|
u64 val = U64_MAX;
|
2015-08-18 15:55:34 -06: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;
|
|
|
|
if (!strcmp(tok, "rbps"))
|
|
|
|
v[0] = val;
|
|
|
|
else if (!strcmp(tok, "wbps"))
|
|
|
|
v[1] = val;
|
|
|
|
else if (!strcmp(tok, "riops"))
|
|
|
|
v[2] = min_t(u64, val, UINT_MAX);
|
|
|
|
else if (!strcmp(tok, "wiops"))
|
|
|
|
v[3] = min_t(u64, val, UINT_MAX);
|
2017-03-27 11:51:42 -06: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-27 11:51:44 -06:00
|
|
|
else if (off == LIMIT_LOW && !strcmp(tok, "latency"))
|
|
|
|
latency_time = val;
|
2015-08-18 15:55:34 -06:00
|
|
|
else
|
|
|
|
goto out_finish;
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:32 -06: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-18 15:55:34 -06:00
|
|
|
|
2017-03-27 11:51:32 -06: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-17 14:07:27 -06: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-17 14:07:24 -06:00
|
|
|
tg->idletime_threshold = tg->idletime_threshold_conf;
|
|
|
|
tg->latency_target = tg->latency_target_conf;
|
2017-03-27 11:51:32 -06:00
|
|
|
}
|
2017-05-17 14:07:27 -06: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-17 14:07:26 -06:00
|
|
|
tg_conf_updated(tg, index == LIMIT_LOW &&
|
|
|
|
tg->td->limit_valid[LIMIT_LOW]);
|
2015-08-18 15:55:34 -06:00
|
|
|
ret = 0;
|
|
|
|
out_finish:
|
|
|
|
blkg_conf_finish(&ctx);
|
|
|
|
return ret ?: nbytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct cftype throtl_files[] = {
|
2017-03-27 11:51:32 -06: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-18 15:55:34 -06:00
|
|
|
{
|
|
|
|
.name = "max",
|
|
|
|
.flags = CFTYPE_NOT_ON_ROOT,
|
2017-03-27 11:51:32 -06:00
|
|
|
.seq_show = tg_print_limit,
|
|
|
|
.write = tg_set_limit,
|
|
|
|
.private = LIMIT_MAX,
|
2015-08-18 15:55:34 -06:00
|
|
|
},
|
|
|
|
{ } /* terminate */
|
|
|
|
};
|
|
|
|
|
2011-03-02 17:05:33 -07:00
|
|
|
static void throtl_shutdown_wq(struct request_queue *q)
|
2010-09-15 15:06:35 -06:00
|
|
|
{
|
|
|
|
struct throtl_data *td = q->td;
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
cancel_work_sync(&td->dispatch_work);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2012-04-16 14:57:25 -06:00
|
|
|
static struct blkcg_policy blkcg_policy_throtl = {
|
2015-08-18 15:55:34 -06:00
|
|
|
.dfl_cftypes = throtl_files,
|
2015-08-18 15:55:30 -06:00
|
|
|
.legacy_cftypes = throtl_legacy_files,
|
2012-04-16 14:57:27 -06:00
|
|
|
|
2015-08-18 15:55:11 -06:00
|
|
|
.pd_alloc_fn = throtl_pd_alloc,
|
2012-04-16 14:57:27 -06:00
|
|
|
.pd_init_fn = throtl_pd_init,
|
2013-05-14 14:52:38 -06:00
|
|
|
.pd_online_fn = throtl_pd_online,
|
2017-03-27 11:51:32 -06:00
|
|
|
.pd_offline_fn = throtl_pd_offline,
|
2015-08-18 15:55:11 -06:00
|
|
|
.pd_free_fn = throtl_pd_free,
|
2010-09-15 15:06:35 -06:00
|
|
|
};
|
|
|
|
|
2017-03-27 11:51:35 -06: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);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* tg should not be an intermediate node */
|
|
|
|
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-27 11:51:41 -06: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-17 14:07:27 -06: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-27 11:51:41 -06:00
|
|
|
* - average think time is more than threshold
|
2017-03-27 16:19:43 -06: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-27 11:51:41 -06:00
|
|
|
*/
|
2017-05-17 14:07:27 -06:00
|
|
|
unsigned long time;
|
2017-05-17 14:07:25 -06: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-27 11:51:41 -06:00
|
|
|
|
2017-05-17 14:07:27 -06: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-27 16:19:43 -06:00
|
|
|
tg->bad_bio_cnt * 5 < tg->bio_cnt);
|
2017-05-17 14:07:25 -06: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-27 11:51:41 -06:00
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:34 -06:00
|
|
|
static bool throtl_tg_can_upgrade(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
|
|
|
bool read_limit, write_limit;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* if cgroup reaches low limit (if low limit is 0, the cgroup always
|
|
|
|
* reaches), it's ok to upgrade to next limit
|
|
|
|
*/
|
|
|
|
read_limit = tg->bps[READ][LIMIT_LOW] || tg->iops[READ][LIMIT_LOW];
|
|
|
|
write_limit = tg->bps[WRITE][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW];
|
|
|
|
if (!read_limit && !write_limit)
|
|
|
|
return true;
|
|
|
|
if (read_limit && sq->nr_queued[READ] &&
|
|
|
|
(!write_limit || sq->nr_queued[WRITE]))
|
|
|
|
return true;
|
|
|
|
if (write_limit && sq->nr_queued[WRITE] &&
|
|
|
|
(!read_limit || sq->nr_queued[READ]))
|
|
|
|
return true;
|
2017-03-27 11:51:39 -06:00
|
|
|
|
|
|
|
if (time_after_eq(jiffies,
|
2017-03-27 11:51:43 -06:00
|
|
|
tg_last_low_overflow_time(tg) + tg->td->throtl_slice) &&
|
|
|
|
throtl_tg_is_idle(tg))
|
2017-03-27 11:51:39 -06:00
|
|
|
return true;
|
2017-03-27 11:51:34 -06: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-27 11:51:37 -06:00
|
|
|
if (time_before(jiffies, td->low_downgrade_time + td->throtl_slice))
|
2017-03-27 11:51:35 -06:00
|
|
|
return false;
|
|
|
|
|
2017-03-27 11:51:34 -06:00
|
|
|
rcu_read_lock();
|
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg) {
|
|
|
|
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-27 11:51:43 -06: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-27 11:51:34 -06:00
|
|
|
static void throtl_upgrade_state(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
struct cgroup_subsys_state *pos_css;
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
|
2017-05-17 14:07:25 -06:00
|
|
|
throtl_log(&td->service_queue, "upgrade to max");
|
2017-03-27 11:51:34 -06:00
|
|
|
td->limit_index = LIMIT_MAX;
|
2017-03-27 11:51:35 -06: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-27 11:51:40 -06:00
|
|
|
td->scale = 0;
|
2017-03-27 11:51:34 -06:00
|
|
|
rcu_read_lock();
|
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg) {
|
|
|
|
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 00:38:49 -06:00
|
|
|
throtl_schedule_next_dispatch(sq, true);
|
2017-03-27 11:51:34 -06: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 00:38:49 -06:00
|
|
|
throtl_schedule_next_dispatch(&td->service_queue, true);
|
2017-03-27 11:51:34 -06:00
|
|
|
queue_work(kthrotld_workqueue, &td->dispatch_work);
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:35 -06:00
|
|
|
static void throtl_downgrade_state(struct throtl_data *td, int new)
|
|
|
|
{
|
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-27 11:51:40 -06:00
|
|
|
td->scale /= 2;
|
|
|
|
|
2017-05-17 14:07:25 -06: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-27 11:51:40 -06:00
|
|
|
if (td->scale) {
|
|
|
|
td->low_upgrade_time = jiffies - td->scale * td->throtl_slice;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:35 -06:00
|
|
|
td->limit_index = new;
|
|
|
|
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
|
|
|
|
*/
|
2017-03-27 11:51:37 -06:00
|
|
|
if (time_after_eq(now, td->low_upgrade_time + td->throtl_slice) &&
|
|
|
|
time_after_eq(now, tg_last_low_overflow_time(tg) +
|
2017-03-27 11:51:43 -06:00
|
|
|
td->throtl_slice) &&
|
|
|
|
(!throtl_tg_is_idle(tg) ||
|
|
|
|
!list_empty(&tg_to_blkg(tg)->blkcg->css.children)))
|
2017-03-27 11:51:35 -06:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool throtl_hierarchy_can_downgrade(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
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-27 11:51:37 -06:00
|
|
|
if (time_after(tg->last_check_time + tg->td->throtl_slice, now))
|
2017-03-27 11:51:35 -06:00
|
|
|
return;
|
|
|
|
|
|
|
|
elapsed_time = now - tg->last_check_time;
|
|
|
|
tg->last_check_time = now;
|
|
|
|
|
2017-03-27 11:51:37 -06:00
|
|
|
if (time_before(now, tg_last_low_overflow_time(tg) +
|
|
|
|
tg->td->throtl_slice))
|
2017-03-27 11:51:35 -06: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))
|
|
|
|
throtl_downgrade_state(tg->td, LIMIT_LOW);
|
|
|
|
|
|
|
|
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-27 11:51:41 -06:00
|
|
|
static void blk_throtl_update_idletime(struct throtl_grp *tg)
|
|
|
|
{
|
|
|
|
unsigned long now = ktime_get_ns() >> 10;
|
|
|
|
unsigned long last_finish_time = tg->last_finish_time;
|
|
|
|
|
|
|
|
if (now <= last_finish_time || last_finish_time == 0 ||
|
|
|
|
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-27 16:19:42 -06:00
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
static void throtl_update_latency_buckets(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
struct avg_latency_bucket avg_latency[LATENCY_BUCKET_SIZE];
|
|
|
|
int i, cpu;
|
|
|
|
unsigned long last_latency = 0;
|
|
|
|
unsigned long latency;
|
|
|
|
|
|
|
|
if (!blk_queue_nonrot(td->queue))
|
|
|
|
return;
|
|
|
|
if (time_before(jiffies, td->last_calculate_time + HZ))
|
|
|
|
return;
|
|
|
|
td->last_calculate_time = jiffies;
|
|
|
|
|
|
|
|
memset(avg_latency, 0, sizeof(avg_latency));
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++) {
|
|
|
|
struct latency_bucket *tmp = &td->tmp_buckets[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, cpu);
|
|
|
|
tmp->total_latency += bucket[i].total_latency;
|
|
|
|
tmp->samples += bucket[i].samples;
|
|
|
|
bucket[i].total_latency = 0;
|
|
|
|
bucket[i].samples = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tmp->samples >= 32) {
|
|
|
|
int samples = tmp->samples;
|
|
|
|
|
|
|
|
latency = tmp->total_latency;
|
|
|
|
|
|
|
|
tmp->total_latency = 0;
|
|
|
|
tmp->samples = 0;
|
|
|
|
latency /= samples;
|
|
|
|
if (latency == 0)
|
|
|
|
continue;
|
|
|
|
avg_latency[i].latency = latency;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++) {
|
|
|
|
if (!avg_latency[i].latency) {
|
|
|
|
if (td->avg_buckets[i].latency < last_latency)
|
|
|
|
td->avg_buckets[i].latency = last_latency;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!td->avg_buckets[i].valid)
|
|
|
|
latency = avg_latency[i].latency;
|
|
|
|
else
|
|
|
|
latency = (td->avg_buckets[i].latency * 7 +
|
|
|
|
avg_latency[i].latency) >> 3;
|
|
|
|
|
|
|
|
td->avg_buckets[i].latency = max(latency, last_latency);
|
|
|
|
td->avg_buckets[i].valid = true;
|
|
|
|
last_latency = td->avg_buckets[i].latency;
|
|
|
|
}
|
2017-05-17 14:07:25 -06:00
|
|
|
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++)
|
|
|
|
throtl_log(&td->service_queue,
|
|
|
|
"Latency bucket %d: latency=%ld, valid=%d", i,
|
|
|
|
td->avg_buckets[i].latency, td->avg_buckets[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-27 16:19:42 -06:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void throtl_update_latency_buckets(struct throtl_data *td)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-04-20 09:41:36 -06:00
|
|
|
static void blk_throtl_assoc_bio(struct throtl_grp *tg, struct bio *bio)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
2017-07-12 12:49:54 -06:00
|
|
|
if (bio->bi_css)
|
2017-04-20 09:41:36 -06:00
|
|
|
bio->bi_cg_private = tg;
|
|
|
|
blk_stat_set_issue(&bio->bi_issue_stat, bio_sectors(bio));
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2015-08-18 15:55:20 -06:00
|
|
|
bool blk_throtl_bio(struct request_queue *q, struct blkcg_gq *blkg,
|
|
|
|
struct bio *bio)
|
2010-09-15 15:06:35 -06: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-14 14:52:38 -06:00
|
|
|
struct throtl_qnode *qn = NULL;
|
2015-08-18 15:55:20 -06:00
|
|
|
struct throtl_grp *tg = blkg_to_tg(blkg ?: q->root_blkg);
|
2013-05-14 14:52:35 -06:00
|
|
|
struct throtl_service_queue *sq;
|
2013-05-14 14:52:35 -06:00
|
|
|
bool rw = bio_data_dir(bio);
|
2011-10-19 06:33:01 -06: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-27 16:19:42 -06:00
|
|
|
struct throtl_data *td = tg->td;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2015-08-18 15:55:20 -06:00
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
/* see throtl_charge_bio() */
|
2016-10-20 07:12:12 -06:00
|
|
|
if (bio_flagged(bio, BIO_THROTTLED) || !tg->has_rules[rw])
|
2011-10-19 06:33:01 -06:00
|
|
|
goto out;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
spin_lock_irq(q->queue_lock);
|
2015-08-18 15:55:19 -06: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-27 16:19:42 -06:00
|
|
|
throtl_update_latency_buckets(td);
|
|
|
|
|
2015-08-18 15:55:19 -06:00
|
|
|
if (unlikely(blk_queue_bypass(q)))
|
2011-10-19 06:33:01 -06:00
|
|
|
goto out_unlock;
|
2011-05-19 13:38:23 -06:00
|
|
|
|
2017-04-20 09:41:36 -06:00
|
|
|
blk_throtl_assoc_bio(tg, 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-27 11:51:41 -06:00
|
|
|
blk_throtl_update_idletime(tg);
|
|
|
|
|
2013-05-14 14:52:35 -06:00
|
|
|
sq = &tg->service_queue;
|
|
|
|
|
2017-03-27 11:51:34 -06:00
|
|
|
again:
|
2013-05-14 14:52:38 -06:00
|
|
|
while (true) {
|
2017-03-27 11:51:35 -06:00
|
|
|
if (tg->last_low_overflow_time[rw] == 0)
|
|
|
|
tg->last_low_overflow_time[rw] = jiffies;
|
|
|
|
throtl_downgrade_check(tg);
|
2017-03-27 11:51:43 -06:00
|
|
|
throtl_upgrade_check(tg);
|
2013-05-14 14:52:38 -06:00
|
|
|
/* throtl is FIFO - if bios are already queued, should queue */
|
|
|
|
if (sq->nr_queued[rw])
|
|
|
|
break;
|
2011-03-07 13:09:32 -07:00
|
|
|
|
2013-05-14 14:52:38 -06:00
|
|
|
/* if above limits, break to queue */
|
2017-03-27 11:51:34 -06:00
|
|
|
if (!tg_may_dispatch(tg, bio, NULL)) {
|
2017-03-27 11:51:35 -06: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-27 16:19:42 -06:00
|
|
|
if (throtl_can_upgrade(td, tg)) {
|
|
|
|
throtl_upgrade_state(td);
|
2017-03-27 11:51:34 -06:00
|
|
|
goto again;
|
|
|
|
}
|
2013-05-14 14:52:38 -06:00
|
|
|
break;
|
2017-03-27 11:51:34 -06:00
|
|
|
}
|
2013-05-14 14:52:38 -06:00
|
|
|
|
|
|
|
/* within limits, let's charge and dispatch directly */
|
2010-09-15 15:06:35 -06:00
|
|
|
throtl_charge_bio(tg, bio);
|
2011-03-22 14:54:29 -06: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-14 14:52:32 -06:00
|
|
|
throtl_trim_slice(tg, rw);
|
2013-05-14 14:52:38 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* @bio passed through this layer without being throttled.
|
|
|
|
* Climb up the ladder. If we''re already at the top, it
|
|
|
|
* 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-14 14:52:38 -06:00
|
|
|
qn = &tg->qnode_on_parent[rw];
|
2013-05-14 14:52:38 -06:00
|
|
|
sq = sq->parent_sq;
|
|
|
|
tg = sq_to_tg(sq);
|
|
|
|
if (!tg)
|
|
|
|
goto out_unlock;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2013-05-14 14:52:38 -06:00
|
|
|
/* out-of-limit, queue to @tg */
|
2013-05-14 14:52:36 -06: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-27 11:51:30 -06: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-14 14:52:36 -06:00
|
|
|
sq->nr_queued[READ], sq->nr_queued[WRITE]);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2017-03-27 11:51:35 -06: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-27 16:19:42 -06: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-14 14:52:38 -06:00
|
|
|
throtl_add_bio_tg(bio, qn, tg);
|
2011-10-19 06:33:01 -06:00
|
|
|
throttled = true;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:37 -06: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-14 14:52:35 -06:00
|
|
|
if (tg->flags & THROTL_TG_WAS_EMPTY) {
|
2013-05-14 14:52:36 -06:00
|
|
|
tg_update_disptime(tg);
|
2013-05-14 14:52:37 -06:00
|
|
|
throtl_schedule_next_dispatch(tg->service_queue.parent_sq, true);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2011-10-19 06:33:01 -06:00
|
|
|
out_unlock:
|
2010-09-15 15:06:35 -06:00
|
|
|
spin_unlock_irq(q->queue_lock);
|
2011-10-19 06:33:01 -06:00
|
|
|
out:
|
2013-05-14 14:52:36 -06:00
|
|
|
/*
|
|
|
|
* As multiple blk-throtls may stack in the same issue path, we
|
|
|
|
* don't want bios to leave with the flag set. Clear the flag if
|
|
|
|
* being issued.
|
|
|
|
*/
|
|
|
|
if (!throttled)
|
2016-10-20 07:12:12 -06:00
|
|
|
bio_clear_flag(bio, BIO_THROTTLED);
|
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-27 16:19:42 -06:00
|
|
|
|
|
|
|
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
if (throttled || !td->track_bio_latency)
|
|
|
|
bio->bi_issue_stat.stat |= SKIP_LATENCY;
|
|
|
|
#endif
|
2011-10-19 06:33:01 -06:00
|
|
|
return throttled;
|
2010-09-15 15:06:35 -06: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-27 11:51:41 -06: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-27 16:19:42 -06:00
|
|
|
static void throtl_track_latency(struct throtl_data *td, sector_t size,
|
|
|
|
int op, unsigned long time)
|
|
|
|
{
|
|
|
|
struct latency_bucket *latency;
|
|
|
|
int index;
|
|
|
|
|
|
|
|
if (!td || td->limit_index != LIMIT_LOW || op != REQ_OP_READ ||
|
|
|
|
!blk_queue_nonrot(td->queue))
|
|
|
|
return;
|
|
|
|
|
|
|
|
index = request_bucket_index(size);
|
|
|
|
|
|
|
|
latency = get_cpu_ptr(td->latency_buckets);
|
|
|
|
latency[index].total_latency += time;
|
|
|
|
latency[index].samples++;
|
|
|
|
put_cpu_ptr(td->latency_buckets);
|
|
|
|
}
|
|
|
|
|
|
|
|
void blk_throtl_stat_add(struct request *rq, u64 time_ns)
|
|
|
|
{
|
|
|
|
struct request_queue *q = rq->q;
|
|
|
|
struct throtl_data *td = q->td;
|
|
|
|
|
|
|
|
throtl_track_latency(td, blk_stat_size(&rq->issue_stat),
|
|
|
|
req_op(rq), time_ns >> 10);
|
|
|
|
}
|
|
|
|
|
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-27 11:51:41 -06:00
|
|
|
void blk_throtl_bio_endio(struct bio *bio)
|
|
|
|
{
|
|
|
|
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-27 16:19:42 -06:00
|
|
|
u64 finish_time_ns;
|
|
|
|
unsigned long finish_time;
|
|
|
|
unsigned long start_time;
|
|
|
|
unsigned long lat;
|
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-27 11:51:41 -06:00
|
|
|
|
|
|
|
tg = bio->bi_cg_private;
|
|
|
|
if (!tg)
|
|
|
|
return;
|
|
|
|
bio->bi_cg_private = NULL;
|
|
|
|
|
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-27 16:19:42 -06:00
|
|
|
finish_time_ns = ktime_get_ns();
|
|
|
|
tg->last_finish_time = finish_time_ns >> 10;
|
|
|
|
|
|
|
|
start_time = blk_stat_time(&bio->bi_issue_stat) >> 10;
|
|
|
|
finish_time = __blk_stat_time(finish_time_ns) >> 10;
|
2017-03-27 16:19:43 -06:00
|
|
|
if (!start_time || finish_time <= start_time)
|
|
|
|
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-27 16:19:42 -06:00
|
|
|
/* this is only for bio based driver */
|
2017-03-27 16:19:43 -06:00
|
|
|
if (!(bio->bi_issue_stat.stat & 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-27 16:19:42 -06:00
|
|
|
throtl_track_latency(tg->td, blk_stat_size(&bio->bi_issue_stat),
|
|
|
|
bio_op(bio), lat);
|
2017-03-27 16:19:43 -06:00
|
|
|
|
2017-06-06 13:40:43 -06:00
|
|
|
if (tg->latency_target && lat >= tg->td->filtered_latency) {
|
2017-03-27 16:19:43 -06:00
|
|
|
int bucket;
|
|
|
|
unsigned int threshold;
|
|
|
|
|
|
|
|
bucket = request_bucket_index(
|
|
|
|
blk_stat_size(&bio->bi_issue_stat));
|
|
|
|
threshold = tg->td->avg_buckets[bucket].latency +
|
|
|
|
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-27 16:19:42 -06: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-27 11:51:41 -06:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/*
|
|
|
|
* Dispatch all bios from all children tg's queued on @parent_sq. On
|
|
|
|
* return, @parent_sq is guaranteed to not have any active children tg's
|
|
|
|
* and all bios from previously active tg's are on @parent_sq->bio_lists[].
|
|
|
|
*/
|
|
|
|
static void tg_drain_bios(struct throtl_service_queue *parent_sq)
|
|
|
|
{
|
|
|
|
struct throtl_grp *tg;
|
|
|
|
|
|
|
|
while ((tg = throtl_rb_first(parent_sq))) {
|
|
|
|
struct throtl_service_queue *sq = &tg->service_queue;
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
throtl_dequeue_tg(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-14 14:52:38 -06:00
|
|
|
while ((bio = throtl_peek_queued(&sq->queued[READ])))
|
2013-05-14 14:52:37 -06:00
|
|
|
tg_dispatch_one_bio(tg, 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-14 14:52:38 -06:00
|
|
|
while ((bio = throtl_peek_queued(&sq->queued[WRITE])))
|
2013-05-14 14:52:37 -06:00
|
|
|
tg_dispatch_one_bio(tg, bio_data_dir(bio));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 06:42:16 -06:00
|
|
|
/**
|
|
|
|
* blk_throtl_drain - drain throttled bios
|
|
|
|
* @q: request_queue to drain throttled bios for
|
|
|
|
*
|
|
|
|
* Dispatch all currently throttled bios on @q through ->make_request_fn().
|
|
|
|
*/
|
|
|
|
void blk_throtl_drain(struct request_queue *q)
|
|
|
|
__releases(q->queue_lock) __acquires(q->queue_lock)
|
|
|
|
{
|
|
|
|
struct throtl_data *td = q->td;
|
2013-05-14 14:52:37 -06:00
|
|
|
struct blkcg_gq *blkg;
|
2013-08-08 18:11:25 -06:00
|
|
|
struct cgroup_subsys_state *pos_css;
|
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 06:42:16 -06:00
|
|
|
struct bio *bio;
|
2013-05-14 14:52:35 -06:00
|
|
|
int rw;
|
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 06:42:16 -06:00
|
|
|
|
2012-03-30 04:33:28 -06:00
|
|
|
queue_lockdep_assert_held(q);
|
2013-05-14 14:52:37 -06:00
|
|
|
rcu_read_lock();
|
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 06:42:16 -06:00
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/*
|
|
|
|
* Drain each tg while doing post-order walk on the blkg tree, so
|
|
|
|
* that all bios are propagated to td->service_queue. It'd be
|
|
|
|
* better to walk service_queue tree directly but blkg walk is
|
|
|
|
* easier.
|
|
|
|
*/
|
2013-08-08 18:11:25 -06:00
|
|
|
blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg)
|
2013-05-14 14:52:37 -06:00
|
|
|
tg_drain_bios(&blkg_to_tg(blkg)->service_queue);
|
2013-05-14 14:52:35 -06:00
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/* finally, transfer bios from top-level tg's into the td */
|
|
|
|
tg_drain_bios(&td->service_queue);
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
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 06:42:16 -06:00
|
|
|
spin_unlock_irq(q->queue_lock);
|
|
|
|
|
2013-05-14 14:52:37 -06:00
|
|
|
/* all bios now should be in td->service_queue, issue them */
|
2013-05-14 14:52:35 -06:00
|
|
|
for (rw = READ; rw <= WRITE; 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-14 14:52:38 -06:00
|
|
|
while ((bio = throtl_pop_queued(&td->service_queue.queued[rw],
|
|
|
|
NULL)))
|
2013-05-14 14:52:35 -06:00
|
|
|
generic_make_request(bio);
|
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 06:42:16 -06:00
|
|
|
|
|
|
|
spin_lock_irq(q->queue_lock);
|
|
|
|
}
|
|
|
|
|
2010-09-15 15:06:35 -06:00
|
|
|
int blk_throtl_init(struct request_queue *q)
|
|
|
|
{
|
|
|
|
struct throtl_data *td;
|
2012-04-13 14:11:33 -06:00
|
|
|
int ret;
|
2010-09-15 15:06:35 -06:00
|
|
|
|
|
|
|
td = kzalloc_node(sizeof(*td), GFP_KERNEL, q->node);
|
|
|
|
if (!td)
|
|
|
|
return -ENOMEM;
|
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-27 16:19:42 -06:00
|
|
|
td->latency_buckets = __alloc_percpu(sizeof(struct latency_bucket) *
|
|
|
|
LATENCY_BUCKET_SIZE, __alignof__(u64));
|
|
|
|
if (!td->latency_buckets) {
|
|
|
|
kfree(td);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2013-05-14 14:52:36 -06:00
|
|
|
INIT_WORK(&td->dispatch_work, blk_throtl_dispatch_work_fn);
|
2015-08-18 15:55:13 -06:00
|
|
|
throtl_service_queue_init(&td->service_queue);
|
2010-09-15 15:06:35 -06:00
|
|
|
|
2012-03-05 14:15:06 -07:00
|
|
|
q->td = td;
|
2011-05-19 13:38:24 -06:00
|
|
|
td->queue = q;
|
2010-10-01 06:49:48 -06:00
|
|
|
|
2017-03-27 11:51:30 -06:00
|
|
|
td->limit_valid[LIMIT_MAX] = true;
|
2017-03-27 11:51:32 -06:00
|
|
|
td->limit_index = LIMIT_MAX;
|
2017-03-27 11:51:35 -06: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-27 11:51:41 -06:00
|
|
|
|
2012-04-13 14:11:33 -06:00
|
|
|
/* activate policy */
|
2012-04-16 14:57:25 -06:00
|
|
|
ret = blkcg_activate_policy(q, &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-27 16:19:42 -06:00
|
|
|
if (ret) {
|
|
|
|
free_percpu(td->latency_buckets);
|
2012-03-05 14:15:05 -07: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-27 16:19:42 -06:00
|
|
|
}
|
2012-04-13 14:11:33 -06:00
|
|
|
return ret;
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
void blk_throtl_exit(struct request_queue *q)
|
|
|
|
{
|
2012-03-05 14:15:22 -07:00
|
|
|
BUG_ON(!q->td);
|
2011-03-02 17:05:33 -07:00
|
|
|
throtl_shutdown_wq(q);
|
2012-04-16 14:57:25 -06:00
|
|
|
blkcg_deactivate_policy(q, &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-27 16:19:42 -06:00
|
|
|
free_percpu(q->td->latency_buckets);
|
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 06:42:16 -06:00
|
|
|
kfree(q->td);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:38 -06:00
|
|
|
void blk_throtl_register_queue(struct request_queue *q)
|
|
|
|
{
|
|
|
|
struct throtl_data *td;
|
2017-06-06 13:40:43 -06:00
|
|
|
int i;
|
2017-03-27 11:51:38 -06:00
|
|
|
|
|
|
|
td = q->td;
|
|
|
|
BUG_ON(!td);
|
|
|
|
|
2017-06-06 13:40:43 -06:00
|
|
|
if (blk_queue_nonrot(q)) {
|
2017-03-27 11:51:38 -06:00
|
|
|
td->throtl_slice = DFL_THROTL_SLICE_SSD;
|
2017-06-06 13:40:43 -06:00
|
|
|
td->filtered_latency = LATENCY_FILTERED_SSD;
|
|
|
|
} else {
|
2017-03-27 11:51:38 -06:00
|
|
|
td->throtl_slice = DFL_THROTL_SLICE_HD;
|
2017-06-06 13:40:43 -06:00
|
|
|
td->filtered_latency = LATENCY_FILTERED_HD;
|
|
|
|
for (i = 0; i < LATENCY_BUCKET_SIZE; i++)
|
|
|
|
td->avg_buckets[i].latency = DFL_HD_BASELINE_LATENCY;
|
|
|
|
}
|
2017-03-27 11:51:38 -06:00
|
|
|
#ifndef CONFIG_BLK_DEV_THROTTLING_LOW
|
|
|
|
/* if no low limit, use previous default */
|
|
|
|
td->throtl_slice = DFL_THROTL_SLICE_HD;
|
|
|
|
#endif
|
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-27 11:51:41 -06: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-27 16:19:42 -06:00
|
|
|
td->track_bio_latency = !q->mq_ops && !q->request_fn;
|
|
|
|
if (!td->track_bio_latency)
|
|
|
|
blk_stat_enable_accounting(q);
|
2017-03-27 11:51:38 -06:00
|
|
|
}
|
|
|
|
|
2017-03-27 11:51:37 -06: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-15 15:06:35 -06:00
|
|
|
static int __init throtl_init(void)
|
|
|
|
{
|
2011-03-01 11:40:54 -07:00
|
|
|
kthrotld_workqueue = alloc_workqueue("kthrotld", WQ_MEM_RECLAIM, 0);
|
|
|
|
if (!kthrotld_workqueue)
|
|
|
|
panic("Failed to create kthrotld\n");
|
|
|
|
|
2012-04-16 14:57:25 -06:00
|
|
|
return blkcg_policy_register(&blkcg_policy_throtl);
|
2010-09-15 15:06:35 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
module_init(throtl_init);
|