2019-04-30 18:42:40 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2017-04-19 14:48:24 +00:00
|
|
|
/*
|
|
|
|
* cgroups support for the BFQ I/O scheduler.
|
|
|
|
*/
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/cgroup.h>
|
|
|
|
#include <linux/ktime.h>
|
|
|
|
#include <linux/rbtree.h>
|
|
|
|
#include <linux/ioprio.h>
|
|
|
|
#include <linux/sbitmap.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
|
2021-09-20 12:33:23 +00:00
|
|
|
#include "elevator.h"
|
2017-04-19 14:48:24 +00:00
|
|
|
#include "bfq-iosched.h"
|
|
|
|
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
2019-06-06 10:26:22 +00:00
|
|
|
static int bfq_stat_init(struct bfq_stat *stat, gfp_t gfp)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = percpu_counter_init(&stat->cpu_cnt, 0, gfp);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
atomic64_set(&stat->aux_cnt, 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void bfq_stat_exit(struct bfq_stat *stat)
|
|
|
|
{
|
|
|
|
percpu_counter_destroy(&stat->cpu_cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_stat_add - add a value to a bfq_stat
|
|
|
|
* @stat: target bfq_stat
|
|
|
|
* @val: value to add
|
|
|
|
*
|
|
|
|
* Add @val to @stat. The caller must ensure that IRQ on the same CPU
|
|
|
|
* don't re-enter this function for the same counter.
|
|
|
|
*/
|
|
|
|
static inline void bfq_stat_add(struct bfq_stat *stat, uint64_t val)
|
|
|
|
{
|
|
|
|
percpu_counter_add_batch(&stat->cpu_cnt, val, BLKG_STAT_CPU_BATCH);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_stat_read - read the current value of a bfq_stat
|
|
|
|
* @stat: bfq_stat to read
|
|
|
|
*/
|
|
|
|
static inline uint64_t bfq_stat_read(struct bfq_stat *stat)
|
|
|
|
{
|
|
|
|
return percpu_counter_sum_positive(&stat->cpu_cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_stat_reset - reset a bfq_stat
|
|
|
|
* @stat: bfq_stat to reset
|
|
|
|
*/
|
|
|
|
static inline void bfq_stat_reset(struct bfq_stat *stat)
|
|
|
|
{
|
|
|
|
percpu_counter_set(&stat->cpu_cnt, 0);
|
|
|
|
atomic64_set(&stat->aux_cnt, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_stat_add_aux - add a bfq_stat into another's aux count
|
|
|
|
* @to: the destination bfq_stat
|
|
|
|
* @from: the source
|
|
|
|
*
|
|
|
|
* Add @from's count including the aux one to @to's aux count.
|
|
|
|
*/
|
|
|
|
static inline void bfq_stat_add_aux(struct bfq_stat *to,
|
|
|
|
struct bfq_stat *from)
|
|
|
|
{
|
|
|
|
atomic64_add(bfq_stat_read(from) + atomic64_read(&from->aux_cnt),
|
|
|
|
&to->aux_cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* blkg_prfill_stat - prfill callback for bfq_stat
|
|
|
|
* @sf: seq_file to print to
|
|
|
|
* @pd: policy private data of interest
|
|
|
|
* @off: offset to the bfq_stat in @pd
|
|
|
|
*
|
|
|
|
* prfill callback for printing a bfq_stat.
|
|
|
|
*/
|
|
|
|
static u64 blkg_prfill_stat(struct seq_file *sf, struct blkg_policy_data *pd,
|
|
|
|
int off)
|
|
|
|
{
|
|
|
|
return __blkg_prfill_u64(sf, pd, bfq_stat_read((void *)pd + off));
|
|
|
|
}
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
/* bfqg stats flags */
|
|
|
|
enum bfqg_stats_flags {
|
|
|
|
BFQG_stats_waiting = 0,
|
|
|
|
BFQG_stats_idling,
|
|
|
|
BFQG_stats_empty,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define BFQG_FLAG_FNS(name) \
|
|
|
|
static void bfqg_stats_mark_##name(struct bfqg_stats *stats) \
|
|
|
|
{ \
|
|
|
|
stats->flags |= (1 << BFQG_stats_##name); \
|
|
|
|
} \
|
|
|
|
static void bfqg_stats_clear_##name(struct bfqg_stats *stats) \
|
|
|
|
{ \
|
|
|
|
stats->flags &= ~(1 << BFQG_stats_##name); \
|
|
|
|
} \
|
|
|
|
static int bfqg_stats_##name(struct bfqg_stats *stats) \
|
|
|
|
{ \
|
|
|
|
return (stats->flags & (1 << BFQG_stats_##name)) != 0; \
|
|
|
|
} \
|
|
|
|
|
|
|
|
BFQG_FLAG_FNS(waiting)
|
|
|
|
BFQG_FLAG_FNS(idling)
|
|
|
|
BFQG_FLAG_FNS(empty)
|
|
|
|
#undef BFQG_FLAG_FNS
|
|
|
|
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
/* This should be called with the scheduler lock held. */
|
2017-04-19 14:48:24 +00:00
|
|
|
static void bfqg_stats_update_group_wait_time(struct bfqg_stats *stats)
|
|
|
|
{
|
2018-05-09 09:08:51 +00:00
|
|
|
u64 now;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
if (!bfqg_stats_waiting(stats))
|
|
|
|
return;
|
|
|
|
|
2024-01-15 21:45:07 +00:00
|
|
|
now = blk_time_get_ns();
|
2018-05-09 09:08:51 +00:00
|
|
|
if (now > stats->start_group_wait_time)
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add(&stats->group_wait_time,
|
2017-04-19 14:48:24 +00:00
|
|
|
now - stats->start_group_wait_time);
|
|
|
|
bfqg_stats_clear_waiting(stats);
|
|
|
|
}
|
|
|
|
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
/* This should be called with the scheduler lock held. */
|
2017-04-19 14:48:24 +00:00
|
|
|
static void bfqg_stats_set_start_group_wait_time(struct bfq_group *bfqg,
|
|
|
|
struct bfq_group *curr_bfqg)
|
|
|
|
{
|
|
|
|
struct bfqg_stats *stats = &bfqg->stats;
|
|
|
|
|
|
|
|
if (bfqg_stats_waiting(stats))
|
|
|
|
return;
|
|
|
|
if (bfqg == curr_bfqg)
|
|
|
|
return;
|
2024-01-15 21:45:07 +00:00
|
|
|
stats->start_group_wait_time = blk_time_get_ns();
|
2017-04-19 14:48:24 +00:00
|
|
|
bfqg_stats_mark_waiting(stats);
|
|
|
|
}
|
|
|
|
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
/* This should be called with the scheduler lock held. */
|
2017-04-19 14:48:24 +00:00
|
|
|
static void bfqg_stats_end_empty_time(struct bfqg_stats *stats)
|
|
|
|
{
|
2018-05-09 09:08:51 +00:00
|
|
|
u64 now;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
if (!bfqg_stats_empty(stats))
|
|
|
|
return;
|
|
|
|
|
2024-01-15 21:45:07 +00:00
|
|
|
now = blk_time_get_ns();
|
2018-05-09 09:08:51 +00:00
|
|
|
if (now > stats->start_empty_time)
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add(&stats->empty_time,
|
2017-04-19 14:48:24 +00:00
|
|
|
now - stats->start_empty_time);
|
|
|
|
bfqg_stats_clear_empty(stats);
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfqg_stats_update_dequeue(struct bfq_group *bfqg)
|
|
|
|
{
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add(&bfqg->stats.dequeue, 1);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void bfqg_stats_set_start_empty_time(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfqg_stats *stats = &bfqg->stats;
|
|
|
|
|
|
|
|
if (blkg_rwstat_total(&stats->queued))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* group is already marked empty. This can happen if bfqq got new
|
|
|
|
* request in parent group and moved to this group while being added
|
|
|
|
* to service tree. Just ignore the event and move on.
|
|
|
|
*/
|
|
|
|
if (bfqg_stats_empty(stats))
|
|
|
|
return;
|
|
|
|
|
2024-01-15 21:45:07 +00:00
|
|
|
stats->start_empty_time = blk_time_get_ns();
|
2017-04-19 14:48:24 +00:00
|
|
|
bfqg_stats_mark_empty(stats);
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfqg_stats_update_idle_time(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfqg_stats *stats = &bfqg->stats;
|
|
|
|
|
|
|
|
if (bfqg_stats_idling(stats)) {
|
2024-01-15 21:45:07 +00:00
|
|
|
u64 now = blk_time_get_ns();
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2018-05-09 09:08:51 +00:00
|
|
|
if (now > stats->start_idle_time)
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add(&stats->idle_time,
|
2017-04-19 14:48:24 +00:00
|
|
|
now - stats->start_idle_time);
|
|
|
|
bfqg_stats_clear_idling(stats);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfqg_stats_set_start_idle_time(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfqg_stats *stats = &bfqg->stats;
|
|
|
|
|
2024-01-15 21:45:07 +00:00
|
|
|
stats->start_idle_time = blk_time_get_ns();
|
2017-04-19 14:48:24 +00:00
|
|
|
bfqg_stats_mark_idling(stats);
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfqg_stats_update_avg_queue_size(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfqg_stats *stats = &bfqg->stats;
|
|
|
|
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add(&stats->avg_queue_size_sum,
|
2017-04-19 14:48:24 +00:00
|
|
|
blkg_rwstat_total(&stats->queued));
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add(&stats->avg_queue_size_samples, 1);
|
2017-04-19 14:48:24 +00:00
|
|
|
bfqg_stats_update_group_wait_time(stats);
|
|
|
|
}
|
|
|
|
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
void bfqg_stats_update_io_add(struct bfq_group *bfqg, struct bfq_queue *bfqq,
|
2022-07-14 18:06:33 +00:00
|
|
|
blk_opf_t opf)
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
{
|
2022-07-14 18:06:33 +00:00
|
|
|
blkg_rwstat_add(&bfqg->stats.queued, opf, 1);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
bfqg_stats_end_empty_time(&bfqg->stats);
|
2022-11-02 02:25:42 +00:00
|
|
|
if (!(bfqq == bfqg->bfqd->in_service_queue))
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
bfqg_stats_set_start_group_wait_time(bfqg, bfqq_group(bfqq));
|
|
|
|
}
|
|
|
|
|
2022-07-14 18:06:33 +00:00
|
|
|
void bfqg_stats_update_io_remove(struct bfq_group *bfqg, blk_opf_t opf)
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
{
|
2022-07-14 18:06:33 +00:00
|
|
|
blkg_rwstat_add(&bfqg->stats.queued, opf, -1);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
}
|
|
|
|
|
2022-07-14 18:06:33 +00:00
|
|
|
void bfqg_stats_update_io_merged(struct bfq_group *bfqg, blk_opf_t opf)
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
{
|
2022-07-14 18:06:33 +00:00
|
|
|
blkg_rwstat_add(&bfqg->stats.merged, opf, 1);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
}
|
|
|
|
|
2018-05-09 09:08:51 +00:00
|
|
|
void bfqg_stats_update_completion(struct bfq_group *bfqg, u64 start_time_ns,
|
2022-07-14 18:06:33 +00:00
|
|
|
u64 io_start_time_ns, blk_opf_t opf)
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
{
|
|
|
|
struct bfqg_stats *stats = &bfqg->stats;
|
2024-01-15 21:45:07 +00:00
|
|
|
u64 now = blk_time_get_ns();
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
|
2018-05-09 09:08:51 +00:00
|
|
|
if (now > io_start_time_ns)
|
2022-07-14 18:06:33 +00:00
|
|
|
blkg_rwstat_add(&stats->service_time, opf,
|
2018-05-09 09:08:51 +00:00
|
|
|
now - io_start_time_ns);
|
|
|
|
if (io_start_time_ns > start_time_ns)
|
2022-07-14 18:06:33 +00:00
|
|
|
blkg_rwstat_add(&stats->wait_time, opf,
|
2018-05-09 09:08:51 +00:00
|
|
|
io_start_time_ns - start_time_ns);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
}
|
|
|
|
|
2019-06-06 10:26:24 +00:00
|
|
|
#else /* CONFIG_BFQ_CGROUP_DEBUG */
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
|
2022-07-14 18:06:33 +00:00
|
|
|
void bfqg_stats_update_io_remove(struct bfq_group *bfqg, blk_opf_t opf) { }
|
|
|
|
void bfqg_stats_update_io_merged(struct bfq_group *bfqg, blk_opf_t opf) { }
|
2018-05-09 09:08:51 +00:00
|
|
|
void bfqg_stats_update_completion(struct bfq_group *bfqg, u64 start_time_ns,
|
2022-07-14 18:06:33 +00:00
|
|
|
u64 io_start_time_ns, blk_opf_t opf) { }
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
void bfqg_stats_update_dequeue(struct bfq_group *bfqg) { }
|
|
|
|
void bfqg_stats_set_start_idle_time(struct bfq_group *bfqg) { }
|
|
|
|
|
2019-06-06 10:26:24 +00:00
|
|
|
#endif /* CONFIG_BFQ_CGROUP_DEBUG */
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_BFQ_GROUP_IOSCHED
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
/*
|
|
|
|
* blk-cgroup policy-related handlers
|
|
|
|
* The following functions help in converting between blk-cgroup
|
|
|
|
* internal structures and BFQ-specific structures.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static struct bfq_group *pd_to_bfqg(struct blkg_policy_data *pd)
|
|
|
|
{
|
|
|
|
return pd ? container_of(pd, struct bfq_group, pd) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct blkcg_gq *bfqg_to_blkg(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
return pd_to_blkg(&bfqg->pd);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct bfq_group *blkg_to_bfqg(struct blkcg_gq *blkg)
|
|
|
|
{
|
|
|
|
return pd_to_bfqg(blkg_to_pd(blkg, &blkcg_policy_bfq));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* bfq_group handlers
|
|
|
|
* The following functions help in navigating the bfq_group hierarchy
|
|
|
|
* by allowing to find the parent of a bfq_group or the bfq_group
|
|
|
|
* associated to a bfq_queue.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static struct bfq_group *bfqg_parent(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct blkcg_gq *pblkg = bfqg_to_blkg(bfqg)->parent;
|
|
|
|
|
|
|
|
return pblkg ? blkg_to_bfqg(pblkg) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct bfq_group *bfqq_group(struct bfq_queue *bfqq)
|
|
|
|
{
|
|
|
|
struct bfq_entity *group_entity = bfqq->entity.parent;
|
|
|
|
|
|
|
|
return group_entity ? container_of(group_entity, struct bfq_group,
|
|
|
|
entity) :
|
|
|
|
bfqq->bfqd->root_group;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The following two functions handle get and put of a bfq_group by
|
|
|
|
* wrapping the related blk-cgroup hooks.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void bfqg_get(struct bfq_group *bfqg)
|
|
|
|
{
|
2023-01-03 08:47:55 +00:00
|
|
|
refcount_inc(&bfqg->ref);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
2017-08-30 18:42:08 +00:00
|
|
|
static void bfqg_put(struct bfq_group *bfqg)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
2023-01-03 08:47:55 +00:00
|
|
|
if (refcount_dec_and_test(&bfqg->ref))
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
kfree(bfqg);
|
|
|
|
}
|
|
|
|
|
2020-08-11 06:43:40 +00:00
|
|
|
static void bfqg_and_blkg_get(struct bfq_group *bfqg)
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
{
|
|
|
|
/* see comments in bfq_bic_update_cgroup for why refcounting bfqg */
|
|
|
|
bfqg_get(bfqg);
|
|
|
|
|
|
|
|
blkg_get(bfqg_to_blkg(bfqg));
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfqg_and_blkg_put(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
blkg_put(bfqg_to_blkg(bfqg));
|
2018-09-06 08:05:44 +00:00
|
|
|
|
|
|
|
bfqg_put(bfqg);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
2019-11-07 19:18:00 +00:00
|
|
|
void bfqg_stats_update_legacy_io(struct request_queue *q, struct request *rq)
|
|
|
|
{
|
|
|
|
struct bfq_group *bfqg = blkg_to_bfqg(rq->bio->bi_blkg);
|
|
|
|
|
2019-12-05 12:53:11 +00:00
|
|
|
if (!bfqg)
|
|
|
|
return;
|
|
|
|
|
2019-11-07 19:18:00 +00:00
|
|
|
blkg_rwstat_add(&bfqg->stats.bytes, rq->cmd_flags, blk_rq_bytes(rq));
|
|
|
|
blkg_rwstat_add(&bfqg->stats.ios, rq->cmd_flags, 1);
|
|
|
|
}
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
/* @stats = 0 */
|
|
|
|
static void bfqg_stats_reset(struct bfqg_stats *stats)
|
|
|
|
{
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
2017-04-19 14:48:24 +00:00
|
|
|
/* queued stats shouldn't be cleared */
|
|
|
|
blkg_rwstat_reset(&stats->merged);
|
|
|
|
blkg_rwstat_reset(&stats->service_time);
|
|
|
|
blkg_rwstat_reset(&stats->wait_time);
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_reset(&stats->time);
|
|
|
|
bfq_stat_reset(&stats->avg_queue_size_sum);
|
|
|
|
bfq_stat_reset(&stats->avg_queue_size_samples);
|
|
|
|
bfq_stat_reset(&stats->dequeue);
|
|
|
|
bfq_stat_reset(&stats->group_wait_time);
|
|
|
|
bfq_stat_reset(&stats->idle_time);
|
|
|
|
bfq_stat_reset(&stats->empty_time);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
#endif
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* @to += @from */
|
|
|
|
static void bfqg_stats_add_aux(struct bfqg_stats *to, struct bfqg_stats *from)
|
|
|
|
{
|
|
|
|
if (!to || !from)
|
|
|
|
return;
|
|
|
|
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
2017-04-19 14:48:24 +00:00
|
|
|
/* queued stats shouldn't be cleared */
|
|
|
|
blkg_rwstat_add_aux(&to->merged, &from->merged);
|
|
|
|
blkg_rwstat_add_aux(&to->service_time, &from->service_time);
|
|
|
|
blkg_rwstat_add_aux(&to->wait_time, &from->wait_time);
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add_aux(&from->time, &from->time);
|
|
|
|
bfq_stat_add_aux(&to->avg_queue_size_sum, &from->avg_queue_size_sum);
|
|
|
|
bfq_stat_add_aux(&to->avg_queue_size_samples,
|
2017-04-19 14:48:24 +00:00
|
|
|
&from->avg_queue_size_samples);
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_add_aux(&to->dequeue, &from->dequeue);
|
|
|
|
bfq_stat_add_aux(&to->group_wait_time, &from->group_wait_time);
|
|
|
|
bfq_stat_add_aux(&to->idle_time, &from->idle_time);
|
|
|
|
bfq_stat_add_aux(&to->empty_time, &from->empty_time);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
#endif
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Transfer @bfqg's stats to its parent's aux counts so that the ancestors'
|
|
|
|
* recursive stats can still account for the amount used by this bfqg after
|
|
|
|
* it's gone.
|
|
|
|
*/
|
|
|
|
static void bfqg_stats_xfer_dead(struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfq_group *parent;
|
|
|
|
|
|
|
|
if (!bfqg) /* root_group */
|
|
|
|
return;
|
|
|
|
|
|
|
|
parent = bfqg_parent(bfqg);
|
|
|
|
|
2018-11-15 19:17:28 +00:00
|
|
|
lockdep_assert_held(&bfqg_to_blkg(bfqg)->q->queue_lock);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
if (unlikely(!parent))
|
|
|
|
return;
|
|
|
|
|
|
|
|
bfqg_stats_add_aux(&parent->stats, &bfqg->stats);
|
|
|
|
bfqg_stats_reset(&bfqg->stats);
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfq_init_entity(struct bfq_entity *entity, struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfq_queue *bfqq = bfq_entity_to_bfqq(entity);
|
|
|
|
|
|
|
|
entity->weight = entity->new_weight;
|
|
|
|
entity->orig_weight = entity->new_weight;
|
|
|
|
if (bfqq) {
|
|
|
|
bfqq->ioprio = bfqq->new_ioprio;
|
|
|
|
bfqq->ioprio_class = bfqq->new_ioprio_class;
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
/*
|
|
|
|
* Make sure that bfqg and its associated blkg do not
|
|
|
|
* disappear before entity.
|
|
|
|
*/
|
|
|
|
bfqg_and_blkg_get(bfqg);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
entity->parent = bfqg->my_entity; /* NULL for root group */
|
|
|
|
entity->sched_data = &bfqg->sched_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void bfqg_stats_exit(struct bfqg_stats *stats)
|
|
|
|
{
|
2019-11-07 19:18:00 +00:00
|
|
|
blkg_rwstat_exit(&stats->bytes);
|
|
|
|
blkg_rwstat_exit(&stats->ios);
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
2017-04-19 14:48:24 +00:00
|
|
|
blkg_rwstat_exit(&stats->merged);
|
|
|
|
blkg_rwstat_exit(&stats->service_time);
|
|
|
|
blkg_rwstat_exit(&stats->wait_time);
|
|
|
|
blkg_rwstat_exit(&stats->queued);
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_exit(&stats->time);
|
|
|
|
bfq_stat_exit(&stats->avg_queue_size_sum);
|
|
|
|
bfq_stat_exit(&stats->avg_queue_size_samples);
|
|
|
|
bfq_stat_exit(&stats->dequeue);
|
|
|
|
bfq_stat_exit(&stats->group_wait_time);
|
|
|
|
bfq_stat_exit(&stats->idle_time);
|
|
|
|
bfq_stat_exit(&stats->empty_time);
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
#endif
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int bfqg_stats_init(struct bfqg_stats *stats, gfp_t gfp)
|
|
|
|
{
|
2019-11-07 19:18:00 +00:00
|
|
|
if (blkg_rwstat_init(&stats->bytes, gfp) ||
|
|
|
|
blkg_rwstat_init(&stats->ios, gfp))
|
2021-10-18 02:42:25 +00:00
|
|
|
goto error;
|
2019-11-07 19:18:00 +00:00
|
|
|
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
2017-04-19 14:48:24 +00:00
|
|
|
if (blkg_rwstat_init(&stats->merged, gfp) ||
|
|
|
|
blkg_rwstat_init(&stats->service_time, gfp) ||
|
|
|
|
blkg_rwstat_init(&stats->wait_time, gfp) ||
|
|
|
|
blkg_rwstat_init(&stats->queued, gfp) ||
|
2019-06-06 10:26:22 +00:00
|
|
|
bfq_stat_init(&stats->time, gfp) ||
|
|
|
|
bfq_stat_init(&stats->avg_queue_size_sum, gfp) ||
|
|
|
|
bfq_stat_init(&stats->avg_queue_size_samples, gfp) ||
|
|
|
|
bfq_stat_init(&stats->dequeue, gfp) ||
|
|
|
|
bfq_stat_init(&stats->group_wait_time, gfp) ||
|
|
|
|
bfq_stat_init(&stats->idle_time, gfp) ||
|
2021-10-18 02:42:25 +00:00
|
|
|
bfq_stat_init(&stats->empty_time, gfp))
|
|
|
|
goto error;
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
#endif
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
return 0;
|
2021-10-18 02:42:25 +00:00
|
|
|
|
|
|
|
error:
|
|
|
|
bfqg_stats_exit(stats);
|
|
|
|
return -ENOMEM;
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct bfq_group_data *cpd_to_bfqgd(struct blkcg_policy_data *cpd)
|
|
|
|
{
|
|
|
|
return cpd ? container_of(cpd, struct bfq_group_data, pd) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct bfq_group_data *blkcg_to_bfqgd(struct blkcg *blkcg)
|
|
|
|
{
|
|
|
|
return cpd_to_bfqgd(blkcg_to_cpd(blkcg, &blkcg_policy_bfq));
|
|
|
|
}
|
|
|
|
|
2017-08-30 18:42:08 +00:00
|
|
|
static struct blkcg_policy_data *bfq_cpd_alloc(gfp_t gfp)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct bfq_group_data *bgd;
|
|
|
|
|
|
|
|
bgd = kzalloc(sizeof(*bgd), gfp);
|
|
|
|
if (!bgd)
|
|
|
|
return NULL;
|
|
|
|
|
2023-04-06 14:50:50 +00:00
|
|
|
bgd->weight = CGROUP_WEIGHT_DFL;
|
|
|
|
return &bgd->pd;
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
2017-08-30 18:42:08 +00:00
|
|
|
static void bfq_cpd_free(struct blkcg_policy_data *cpd)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
kfree(cpd_to_bfqgd(cpd));
|
|
|
|
}
|
|
|
|
|
2023-02-03 15:03:58 +00:00
|
|
|
static struct blkg_policy_data *bfq_pd_alloc(struct gendisk *disk,
|
|
|
|
struct blkcg *blkcg, gfp_t gfp)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct bfq_group *bfqg;
|
|
|
|
|
2023-02-03 15:03:58 +00:00
|
|
|
bfqg = kzalloc_node(sizeof(*bfqg), gfp, disk->node_id);
|
2017-04-19 14:48:24 +00:00
|
|
|
if (!bfqg)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (bfqg_stats_init(&bfqg->stats, gfp)) {
|
|
|
|
kfree(bfqg);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
/* see comments in bfq_bic_update_cgroup for why refcounting */
|
2023-01-03 08:47:55 +00:00
|
|
|
refcount_set(&bfqg->ref, 1);
|
2017-04-19 14:48:24 +00:00
|
|
|
return &bfqg->pd;
|
|
|
|
}
|
|
|
|
|
2017-08-30 18:42:08 +00:00
|
|
|
static void bfq_pd_init(struct blkg_policy_data *pd)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct blkcg_gq *blkg = pd_to_blkg(pd);
|
|
|
|
struct bfq_group *bfqg = blkg_to_bfqg(blkg);
|
|
|
|
struct bfq_data *bfqd = blkg->q->elevator->elevator_data;
|
|
|
|
struct bfq_entity *entity = &bfqg->entity;
|
|
|
|
struct bfq_group_data *d = blkcg_to_bfqgd(blkg->blkcg);
|
|
|
|
|
|
|
|
entity->orig_weight = entity->weight = entity->new_weight = d->weight;
|
|
|
|
entity->my_sched_data = &bfqg->sched_data;
|
block, bfq: merge bursts of newly-created queues
Many throughput-sensitive workloads are made of several parallel I/O
flows, with all flows generated by the same application, or more
generically by the same task (e.g., system boot). The most
counterproductive action with these workloads is plugging I/O dispatch
when one of the bfq_queues associated with these flows remains
temporarily empty.
To avoid this plugging, BFQ has been using a burst-handling mechanism
for years now. This mechanism has proven effective for throughput, and
not detrimental for service guarantees. This commit pushes this
mechanism a little bit further, basing on the following two facts.
First, all the I/O flows of a the same application or task contribute
to the execution/completion of that common application or task. So the
performance figures that matter are total throughput of the flows and
task-wide I/O latency. In particular, these flows do not need to be
protected from each other, in terms of individual bandwidth or
latency.
Second, the above fact holds regardless of the number of flows.
Putting these two facts together, this commits merges stably the
bfq_queues associated with these I/O flows, i.e., with the processes
that generate these IO/ flows, regardless of how many the involved
processes are.
To decide whether a set of bfq_queues is actually associated with the
I/O flows of a common application or task, and to merge these queues
stably, this commit operates as follows: given a bfq_queue, say Q2,
currently being created, and the last bfq_queue, say Q1, created
before Q2, Q2 is merged stably with Q1 if
- very little time has elapsed since when Q1 was created
- Q2 has the same ioprio as Q1
- Q2 belongs to the same group as Q1
Merging bfq_queues also reduces scheduling overhead. A fio test with
ten random readers on /dev/nullb shows a throughput boost of 40%, with
a quadcore. Since BFQ's execution time amounts to ~50% of the total
per-request processing time, the above throughput boost implies that
BFQ's overhead is reduced by more than 50%.
Tested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Link: https://lore.kernel.org/r/20210304174627.161-7-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-04 17:46:27 +00:00
|
|
|
entity->last_bfqq_created = NULL;
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
bfqg->my_entity = entity; /*
|
|
|
|
* the root_group's will be set to NULL
|
|
|
|
* in bfq_init_queue()
|
|
|
|
*/
|
|
|
|
bfqg->bfqd = bfqd;
|
|
|
|
bfqg->active_entities = 0;
|
2022-09-16 07:19:38 +00:00
|
|
|
bfqg->num_queues_with_pending_reqs = 0;
|
2017-04-19 14:48:24 +00:00
|
|
|
bfqg->rq_pos_tree = RB_ROOT;
|
|
|
|
}
|
|
|
|
|
2017-08-30 18:42:08 +00:00
|
|
|
static void bfq_pd_free(struct blkg_policy_data *pd)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct bfq_group *bfqg = pd_to_bfqg(pd);
|
|
|
|
|
|
|
|
bfqg_stats_exit(&bfqg->stats);
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
bfqg_put(bfqg);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
2017-08-30 18:42:08 +00:00
|
|
|
static void bfq_pd_reset_stats(struct blkg_policy_data *pd)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct bfq_group *bfqg = pd_to_bfqg(pd);
|
|
|
|
|
|
|
|
bfqg_stats_reset(&bfqg->stats);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void bfq_group_set_parent(struct bfq_group *bfqg,
|
|
|
|
struct bfq_group *parent)
|
|
|
|
{
|
|
|
|
struct bfq_entity *entity;
|
|
|
|
|
|
|
|
entity = &bfqg->entity;
|
|
|
|
entity->parent = parent->my_entity;
|
|
|
|
entity->sched_data = &parent->sched_data;
|
|
|
|
}
|
|
|
|
|
2022-04-01 10:27:49 +00:00
|
|
|
static void bfq_link_bfqg(struct bfq_data *bfqd, struct bfq_group *bfqg)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
2022-04-01 10:27:49 +00:00
|
|
|
struct bfq_group *parent;
|
2017-04-19 14:48:24 +00:00
|
|
|
struct bfq_entity *entity;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update chain of bfq_groups as we might be handling a leaf group
|
|
|
|
* which, along with some of its relatives, has not been hooked yet
|
|
|
|
* to the private hierarchy of BFQ.
|
|
|
|
*/
|
|
|
|
entity = &bfqg->entity;
|
|
|
|
for_each_entity(entity) {
|
2020-03-06 12:27:31 +00:00
|
|
|
struct bfq_group *curr_bfqg = container_of(entity,
|
|
|
|
struct bfq_group, entity);
|
|
|
|
if (curr_bfqg != bfqd->root_group) {
|
|
|
|
parent = bfqg_parent(curr_bfqg);
|
2017-04-19 14:48:24 +00:00
|
|
|
if (!parent)
|
|
|
|
parent = bfqd->root_group;
|
2020-03-06 12:27:31 +00:00
|
|
|
bfq_group_set_parent(curr_bfqg, parent);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
}
|
2022-04-01 10:27:49 +00:00
|
|
|
}
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2022-04-01 10:27:49 +00:00
|
|
|
struct bfq_group *bfq_bio_bfqg(struct bfq_data *bfqd, struct bio *bio)
|
|
|
|
{
|
|
|
|
struct blkcg_gq *blkg = bio->bi_blkg;
|
2022-04-01 10:27:50 +00:00
|
|
|
struct bfq_group *bfqg;
|
2022-04-01 10:27:49 +00:00
|
|
|
|
2022-04-01 10:27:50 +00:00
|
|
|
while (blkg) {
|
block, bfq: fix null pointer dereference in bfq_bio_bfqg()
Out test found a following problem in kernel 5.10, and the same problem
should exist in mainline:
BUG: kernel NULL pointer dereference, address: 0000000000000094
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 7 PID: 155 Comm: kworker/7:1 Not tainted 5.10.0-01932-g19e0ace2ca1d-dirty 4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-b4
Workqueue: kthrotld blk_throtl_dispatch_work_fn
RIP: 0010:bfq_bio_bfqg+0x52/0xc0
Code: 94 00 00 00 00 75 2e 48 8b 40 30 48 83 05 35 06 c8 0b 01 48 85 c0 74 3d 4b
RSP: 0018:ffffc90001a1fba0 EFLAGS: 00010002
RAX: ffff888100d60400 RBX: ffff8881132e7000 RCX: 0000000000000000
RDX: 0000000000000017 RSI: ffff888103580a18 RDI: ffff888103580a18
RBP: ffff8881132e7000 R08: 0000000000000000 R09: ffffc90001a1fe10
R10: 0000000000000a20 R11: 0000000000034320 R12: 0000000000000000
R13: ffff888103580a18 R14: ffff888114447000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88881fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000094 CR3: 0000000100cdb000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
bfq_bic_update_cgroup+0x3c/0x350
? ioc_create_icq+0x42/0x270
bfq_init_rq+0xfd/0x1060
bfq_insert_requests+0x20f/0x1cc0
? ioc_create_icq+0x122/0x270
blk_mq_sched_insert_requests+0x86/0x1d0
blk_mq_flush_plug_list+0x193/0x2a0
blk_flush_plug_list+0x127/0x170
blk_finish_plug+0x31/0x50
blk_throtl_dispatch_work_fn+0x151/0x190
process_one_work+0x27c/0x5f0
worker_thread+0x28b/0x6b0
? rescuer_thread+0x590/0x590
kthread+0x153/0x1b0
? kthread_flush_work+0x170/0x170
ret_from_fork+0x1f/0x30
Modules linked in:
CR2: 0000000000000094
---[ end trace e2e59ac014314547 ]---
RIP: 0010:bfq_bio_bfqg+0x52/0xc0
Code: 94 00 00 00 00 75 2e 48 8b 40 30 48 83 05 35 06 c8 0b 01 48 85 c0 74 3d 4b
RSP: 0018:ffffc90001a1fba0 EFLAGS: 00010002
RAX: ffff888100d60400 RBX: ffff8881132e7000 RCX: 0000000000000000
RDX: 0000000000000017 RSI: ffff888103580a18 RDI: ffff888103580a18
RBP: ffff8881132e7000 R08: 0000000000000000 R09: ffffc90001a1fe10
R10: 0000000000000a20 R11: 0000000000034320 R12: 0000000000000000
R13: ffff888103580a18 R14: ffff888114447000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88881fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000094 CR3: 0000000100cdb000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Root cause is quite complex:
1) use bfq elevator for the test device.
2) create a cgroup CG
3) config blk throtl in CG
blkg_conf_prep
blkg_create
4) create a thread T1 and issue async io in CG:
bio_init
bio_associate_blkg
...
submit_bio
submit_bio_noacct
blk_throtl_bio -> io is throttled
// io submit is done
5) switch elevator:
bfq_exit_queue
blkcg_deactivate_policy
list_for_each_entry(blkg, &q->blkg_list, q_node)
blkg->pd[] = NULL
// bfq policy is removed
5) thread t1 exist, then remove the cgroup CG:
blkcg_unpin_online
blkcg_destroy_blkgs
blkg_destroy
list_del_init(&blkg->q_node)
// blkg is removed from queue list
6) switch elevator back to bfq
bfq_init_queue
bfq_create_group_hierarchy
blkcg_activate_policy
list_for_each_entry_reverse(blkg, &q->blkg_list)
// blkg is removed from list, hence bfq policy is still NULL
7) throttled io is dispatched to bfq:
bfq_insert_requests
bfq_init_rq
bfq_bic_update_cgroup
bfq_bio_bfqg
bfqg = blkg_to_bfqg(blkg)
// bfqg is NULL because bfq policy is NULL
The problem is only possible in bfq because only bfq can be deactivated and
activated while queue is online, while others can only be deactivated while
the device is removed.
Fix the problem in bfq by checking if blkg is online before calling
blkg_to_bfqg().
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20221108103434.2853269-1-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-11-08 10:34:34 +00:00
|
|
|
if (!blkg->online) {
|
|
|
|
blkg = blkg->parent;
|
|
|
|
continue;
|
|
|
|
}
|
2022-04-01 10:27:50 +00:00
|
|
|
bfqg = blkg_to_bfqg(blkg);
|
2023-02-02 13:49:13 +00:00
|
|
|
if (bfqg->pd.online) {
|
2022-04-01 10:27:50 +00:00
|
|
|
bio_associate_blkg_from_css(bio, &blkg->blkcg->css);
|
|
|
|
return bfqg;
|
|
|
|
}
|
|
|
|
blkg = blkg->parent;
|
|
|
|
}
|
|
|
|
bio_associate_blkg_from_css(bio,
|
|
|
|
&bfqg_to_blkg(bfqd->root_group)->blkcg->css);
|
|
|
|
return bfqd->root_group;
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_bfqq_move - migrate @bfqq to @bfqg.
|
|
|
|
* @bfqd: queue descriptor.
|
|
|
|
* @bfqq: the queue to move.
|
|
|
|
* @bfqg: the group to move to.
|
|
|
|
*
|
|
|
|
* Move @bfqq to @bfqg, deactivating it from its old group and reactivating
|
|
|
|
* it on the new one. Avoid putting the entity on the old group idle tree.
|
|
|
|
*
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
* Must be called under the scheduler lock, to make sure that the blkg
|
|
|
|
* owning @bfqg does not disappear (see comments in
|
|
|
|
* bfq_bic_update_cgroup on guaranteeing the consistency of blkg
|
|
|
|
* objects).
|
2017-04-19 14:48:24 +00:00
|
|
|
*/
|
|
|
|
void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
|
|
|
|
struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfq_entity *entity = &bfqq->entity;
|
2022-01-29 01:59:23 +00:00
|
|
|
struct bfq_group *old_parent = bfqq_group(bfqq);
|
2022-09-16 07:19:38 +00:00
|
|
|
bool has_pending_reqs = false;
|
2022-01-29 01:59:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* No point to move bfqq to the same group, which can happen when
|
|
|
|
* root group is offlined
|
|
|
|
*/
|
|
|
|
if (old_parent == bfqg)
|
|
|
|
return;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2022-01-29 01:59:24 +00:00
|
|
|
/*
|
|
|
|
* oom_bfqq is not allowed to move, oom_bfqq will hold ref to root_group
|
|
|
|
* until elevator exit.
|
|
|
|
*/
|
|
|
|
if (bfqq == &bfqd->oom_bfqq)
|
|
|
|
return;
|
2020-03-21 09:45:18 +00:00
|
|
|
/*
|
|
|
|
* Get extra reference to prevent bfqq from being freed in
|
|
|
|
* next possible expire or deactivate.
|
|
|
|
*/
|
|
|
|
bfqq->ref++;
|
|
|
|
|
2022-09-16 07:19:38 +00:00
|
|
|
if (entity->in_groups_with_pending_reqs) {
|
|
|
|
has_pending_reqs = true;
|
|
|
|
bfq_del_bfqq_in_groups_with_pending_reqs(bfqq);
|
|
|
|
}
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
/* If bfqq is empty, then bfq_bfqq_expire also invokes
|
|
|
|
* bfq_del_bfqq_busy, thereby removing bfqq and its entity
|
|
|
|
* from data structures related to current group. Otherwise we
|
|
|
|
* need to remove bfqq explicitly with bfq_deactivate_bfqq, as
|
|
|
|
* we do below.
|
|
|
|
*/
|
|
|
|
if (bfqq == bfqd->in_service_queue)
|
|
|
|
bfq_bfqq_expire(bfqd, bfqd->in_service_queue,
|
|
|
|
false, BFQQE_PREEMPTED);
|
|
|
|
|
|
|
|
if (bfq_bfqq_busy(bfqq))
|
|
|
|
bfq_deactivate_bfqq(bfqd, bfqq, false, false);
|
2020-02-03 10:40:57 +00:00
|
|
|
else if (entity->on_st_or_in_serv)
|
2017-04-19 14:48:24 +00:00
|
|
|
bfq_put_idle_entity(bfq_entity_service_tree(entity), entity);
|
2022-01-29 01:59:23 +00:00
|
|
|
bfqg_and_blkg_put(old_parent);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2024-09-02 13:03:29 +00:00
|
|
|
bfq_reassign_last_bfqq(bfqq, NULL);
|
2017-04-19 14:48:24 +00:00
|
|
|
entity->parent = bfqg->my_entity;
|
|
|
|
entity->sched_data = &bfqg->sched_data;
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
/* pin down bfqg and its associated blkg */
|
|
|
|
bfqg_and_blkg_get(bfqg);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2022-09-16 07:19:38 +00:00
|
|
|
if (has_pending_reqs)
|
|
|
|
bfq_add_bfqq_in_groups_with_pending_reqs(bfqq);
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
if (bfq_bfqq_busy(bfqq)) {
|
block, bfq: do not merge queues on flash storage with queueing
To boost throughput with a set of processes doing interleaved I/O
(i.e., a set of processes whose individual I/O is random, but whose
merged cumulative I/O is sequential), BFQ merges the queues associated
with these processes, i.e., redirects the I/O of these processes into a
common, shared queue. In the shared queue, I/O requests are ordered by
their position on the medium, thus sequential I/O gets dispatched to
the device when the shared queue is served.
Queue merging costs execution time, because, to detect which queues to
merge, BFQ must maintain a list of the head I/O requests of active
queues, ordered by request positions. Measurements showed that this
costs about 10% of BFQ's total per-request processing time.
Request processing time becomes more and more critical as the speed of
the underlying storage device grows. Yet, fortunately, queue merging
is basically useless on the very devices that are so fast to make
request processing time critical. To reach a high throughput, these
devices must have many requests queued at the same time. But, in this
configuration, the internal scheduling algorithms of these devices do
also the job of queue merging: they reorder requests so as to obtain
as much as possible a sequential I/O pattern. As a consequence, with
processes doing interleaved I/O, the throughput reached by one such
device is likely to be the same, with and without queue merging.
In view of this fact, this commit disables queue merging, and all
related housekeeping, for non-rotational devices with internal
queueing. The total, single-lock-protected, per-request processing
time of BFQ drops to, e.g., 1.9 us on an Intel Core i7-2760QM@2.40GHz
(time measured with simple code instrumentation, and using the
throughput-sync.sh script of the S suite [1], in performance-profiling
mode). To put this result into context, the total,
single-lock-protected, per-request execution time of the lightest I/O
scheduler available in blk-mq, mq-deadline, is 0.7 us (mq-deadline is
~800 LOC, against ~10500 LOC for BFQ).
Disabling merging provides a further, remarkable benefit in terms of
throughput. Merging tends to make many workloads artificially more
uneven, mainly because of shared queues remaining non empty for
incomparably more time than normal queues. So, if, e.g., one of the
queues in a set of merged queues has a higher weight than a normal
queue, then the shared queue may inherit such a high weight and, by
staying almost always active, may force BFQ to perform I/O plugging
most of the time. This evidently makes it harder for BFQ to let the
device reach a high throughput.
As a practical example of this problem, and of the benefits of this
commit, we measured again the throughput in the nasty scenario
considered in previous commit messages: dbench test (in the Phoronix
suite), with 6 clients, on a filesystem with journaling, and with the
journaling daemon enjoying a higher weight than normal processes. With
this commit, the throughput grows from ~150 MB/s to ~200 MB/s on a
PLEXTOR PX-256M5 SSD. This is the same peak throughput reached by any
of the other I/O schedulers. As such, this is also likely to be the
maximum possible throughput reachable with this workload on this
device, because I/O is mostly random, and the other schedulers
basically just pass I/O requests to the drive as fast as possible.
[1] https://github.com/Algodev-github/S
Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Tested-by: Francesco Pollicino <fra.fra.800@gmail.com>
Signed-off-by: Alessio Masola <alessio.masola@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-03-12 08:59:30 +00:00
|
|
|
if (unlikely(!bfqd->nonrot_with_queueing))
|
|
|
|
bfq_pos_tree_add_move(bfqd, bfqq);
|
2017-04-19 14:48:24 +00:00
|
|
|
bfq_activate_bfqq(bfqd, bfqq);
|
|
|
|
}
|
|
|
|
|
block, bfq: inject I/O to underutilized actuators
The main service scheme of BFQ for sync I/O is serving one sync
bfq_queue at a time, for a while. In particular, BFQ enforces this
scheme when it deems the latter necessary to boost throughput or
to preserve service guarantees. Unfortunately, when BFQ enforces
this policy, only one actuator at a time gets served for a while,
because each bfq_queue contains I/O only for one actuator. The
other actuators may remain underutilized.
Actually, BFQ may serve (inject) extra I/O, taken from other
bfq_queues, in parallel with that of the in-service queue. This
injection mechanism may provide the ground for dealing also with
the above actuator-underutilization problem. Yet BFQ does not take
the actuator load into account when choosing which queue to pick
extra I/O from. In addition, BFQ may happen to inject extra I/O
only when the in-service queue is temporarily empty.
In view of these facts, this commit extends the
injection mechanism in such a way that the latter:
(1) takes into account also the actuator load;
(2) checks such a load on each dispatch, and injects I/O for an
underutilized actuator, if there is one and there is I/O for it.
To perform the check in (2), this commit introduces a load
threshold, currently set to 4. A linear scan of each actuator is
performed, until an actuator is found for which the following two
conditions hold: the load of the actuator is below the threshold,
and there is at least one non-in-service queue that contains I/O
for that actuator. If such a pair (actuator, queue) is found, then
the head request of that queue is returned for dispatch, instead
of the head request of the in-service queue.
We have set the threshold, empirically, to the minimum possible
value for which an actuator is fully utilized, or close to be
fully utilized. By doing so, injected I/O 'steals' as few
drive-queue slots as possibile to the in-service queue. This
reduces as much as possible the probability that the service of
I/O from the in-service bfq_queue gets delayed because of slot
exhaustion, i.e., because all the slots of the drive queue are
filled with I/O injected from other queues (NCQ provides for 32
slots).
This new mechanism also counters actuator underutilization in the
case of asymmetric configurations of bfq_queues. Namely if there
are few bfq_queues containing I/O for some actuators and many
bfq_queues containing I/O for other actuators. Or if the
bfq_queues containing I/O for some actuators have lower weights
than the other bfq_queues.
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Davide Zini <davidezini2@gmail.com>
Link: https://lore.kernel.org/r/20230103145503.71712-8-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-03 14:55:02 +00:00
|
|
|
if (!bfqd->in_service_queue && !bfqd->tot_rq_in_driver)
|
2017-04-19 14:48:24 +00:00
|
|
|
bfq_schedule_dispatch(bfqd);
|
2020-03-21 09:45:18 +00:00
|
|
|
/* release extra ref taken above, bfqq may happen to be freed now */
|
2020-02-03 10:40:56 +00:00
|
|
|
bfq_put_queue(bfqq);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
block, bfq: split sync bfq_queues on a per-actuator basis
Single-LUN multi-actuator SCSI drives, as well as all multi-actuator
SATA drives appear as a single device to the I/O subsystem [1]. Yet
they address commands to different actuators internally, as a function
of Logical Block Addressing (LBAs). A given sector is reachable by
only one of the actuators. For example, Seagate’s Serial Advanced
Technology Attachment (SATA) version contains two actuators and maps
the lower half of the SATA LBA space to the lower actuator and the
upper half to the upper actuator.
Evidently, to fully utilize actuators, no actuator must be left idle
or underutilized while there is pending I/O for it. The block layer
must somehow control the load of each actuator individually. This
commit lays the ground for allowing BFQ to provide such a per-actuator
control.
BFQ associates an I/O-request sync bfq_queue with each process doing
synchronous I/O, or with a group of processes, in case of queue
merging. Then BFQ serves one bfq_queue at a time. While in service, a
bfq_queue is emptied in request-position order. Yet the same process,
or group of processes, may generate I/O for different actuators. In
this case, different streams of I/O (each for a different actuator)
get all inserted into the same sync bfq_queue. So there is basically
no individual control on when each stream is served, i.e., on when the
I/O requests of the stream are picked from the bfq_queue and
dispatched to the drive.
This commit enables BFQ to control the service of each actuator
individually for synchronous I/O, by simply splitting each sync
bfq_queue into N queues, one for each actuator. In other words, a sync
bfq_queue is now associated to a pair (process, actuator). As a
consequence of this split, the per-queue proportional-share policy
implemented by BFQ will guarantee that the sync I/O generated for each
actuator, by each process, receives its fair share of service.
This is just a preparatory patch. If the I/O of the same process
happens to be sent to different queues, then each of these queues may
undergo queue merging. To handle this event, the bfq_io_cq data
structure must be properly extended. In addition, stable merging must
be disabled to avoid loss of control on individual actuators. Finally,
also async queues must be split. These issues are described in detail
and addressed in next commits. As for this commit, although multiple
per-process bfq_queues are provided, the I/O of each process or group
of processes is still sent to only one queue, regardless of the
actuator the I/O is for. The forwarding to distinct bfq_queues will be
enabled after addressing the above issues.
[1] https://www.linaro.org/blog/budget-fair-queueing-bfq-linux-io-scheduler-optimizations-for-multi-actuator-sata-hard-drives/
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Gabriele Felici <felicigb@gmail.com>
Signed-off-by: Carmine Zaccagnino <carmine@carminezacc.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Link: https://lore.kernel.org/r/20230103145503.71712-2-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-03 14:54:56 +00:00
|
|
|
static void bfq_sync_bfqq_move(struct bfq_data *bfqd,
|
|
|
|
struct bfq_queue *sync_bfqq,
|
|
|
|
struct bfq_io_cq *bic,
|
|
|
|
struct bfq_group *bfqg,
|
|
|
|
unsigned int act_idx)
|
|
|
|
{
|
|
|
|
struct bfq_queue *bfqq;
|
|
|
|
|
|
|
|
if (!sync_bfqq->new_bfqq && !bfq_bfqq_coop(sync_bfqq)) {
|
|
|
|
/* We are the only user of this bfqq, just move it */
|
|
|
|
if (sync_bfqq->entity.sched_data != &bfqg->sched_data)
|
|
|
|
bfq_bfqq_move(bfqd, sync_bfqq, bfqg);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The queue was merged to a different queue. Check
|
|
|
|
* that the merge chain still belongs to the same
|
|
|
|
* cgroup.
|
|
|
|
*/
|
|
|
|
for (bfqq = sync_bfqq; bfqq; bfqq = bfqq->new_bfqq)
|
|
|
|
if (bfqq->entity.sched_data != &bfqg->sched_data)
|
|
|
|
break;
|
|
|
|
if (bfqq) {
|
|
|
|
/*
|
|
|
|
* Some queue changed cgroup so the merge is not valid
|
|
|
|
* anymore. We cannot easily just cancel the merge (by
|
|
|
|
* clearing new_bfqq) as there may be other processes
|
|
|
|
* using this queue and holding refs to all queues
|
|
|
|
* below sync_bfqq->new_bfqq. Similarly if the merge
|
|
|
|
* already happened, we need to detach from bfqq now
|
|
|
|
* so that we cannot merge bio to a request from the
|
|
|
|
* old cgroup.
|
|
|
|
*/
|
|
|
|
bfq_put_cooperator(sync_bfqq);
|
|
|
|
bic_set_bfqq(bic, NULL, true, act_idx);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
/**
|
2022-06-17 21:08:59 +00:00
|
|
|
* __bfq_bic_change_cgroup - move @bic to @bfqg.
|
2017-04-19 14:48:24 +00:00
|
|
|
* @bfqd: the queue descriptor.
|
|
|
|
* @bic: the bic to move.
|
2022-06-17 21:08:59 +00:00
|
|
|
* @bfqg: the group to move to.
|
2017-04-19 14:48:24 +00:00
|
|
|
*
|
block, bfq: access and cache blkg data only when safe
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rcu-protected, blk-mq I/O
schedulers may see inconsistent data when they access blkg and
blkg-related objects. BFQ does access these objects, and does incur
this problem, in the following case.
The blkg_lookup performed in bfq_get_queue, being protected (only)
through rcu, may happen to return the address of a copy of the
original blkg. If this is the case, then the blkg_get performed in
bfq_get_queue, to pin down the blkg, is useless: it does not prevent
blk-cgroup code from destroying both the original blkg and all objects
directly or indirectly referred by the copy of the blkg. BFQ accesses
these objects, which typically causes a crash for NULL-pointer
dereference of memory-protection violation.
Some additional protection mechanism should be added to blk-cgroup to
address this issue. In the meantime, this commit provides a quick
temporary fix for BFQ: cache (when safe) blkg data that might
disappear right after a blkg_lookup.
In particular, this commit exploits the following facts to achieve its
goal without introducing further locks. Destroy operations on a blkg
invoke, as a first step, hooks of the scheduler associated with the
blkg. And these hooks are executed with bfqd->lock held for BFQ. As a
consequence, for any blkg associated with the request queue an
instance of BFQ is attached to, we are guaranteed that such a blkg is
not destroyed, and that all the pointers it contains are consistent,
while that instance is holding its bfqd->lock. A blkg_lookup performed
with bfqd->lock held then returns a fully consistent blkg, which
remains consistent until this lock is held. In more detail, this holds
even if the returned blkg is a copy of the original one.
Finally, also the object describing a group inside BFQ needs to be
protected from destruction on the blkg_free of the original blkg
(which invokes bfq_pd_free). This commit adds private refcounting for
this object, to let it disappear only after no bfq_queue refers to it
any longer.
This commit also removes or updates some stale comments on locking
issues related to blk-cgroup operations.
Reported-by: Tomas Konir <tomas.konir@gmail.com>
Reported-by: Lee Tibbert <lee.tibbert@gmail.com>
Reported-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Tested-by: Tomas Konir <tomas.konir@gmail.com>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Marco Piazza <mpiazza@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-05 08:11:15 +00:00
|
|
|
* Move bic to blkcg, assuming that bfqd->lock is held; which makes
|
|
|
|
* sure that the reference to cgroup is valid across the call (see
|
|
|
|
* comments in bfq_bic_update_cgroup on this issue)
|
2017-04-19 14:48:24 +00:00
|
|
|
*/
|
2022-12-14 03:31:54 +00:00
|
|
|
static void __bfq_bic_change_cgroup(struct bfq_data *bfqd,
|
|
|
|
struct bfq_io_cq *bic,
|
|
|
|
struct bfq_group *bfqg)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
block, bfq: split sync bfq_queues on a per-actuator basis
Single-LUN multi-actuator SCSI drives, as well as all multi-actuator
SATA drives appear as a single device to the I/O subsystem [1]. Yet
they address commands to different actuators internally, as a function
of Logical Block Addressing (LBAs). A given sector is reachable by
only one of the actuators. For example, Seagate’s Serial Advanced
Technology Attachment (SATA) version contains two actuators and maps
the lower half of the SATA LBA space to the lower actuator and the
upper half to the upper actuator.
Evidently, to fully utilize actuators, no actuator must be left idle
or underutilized while there is pending I/O for it. The block layer
must somehow control the load of each actuator individually. This
commit lays the ground for allowing BFQ to provide such a per-actuator
control.
BFQ associates an I/O-request sync bfq_queue with each process doing
synchronous I/O, or with a group of processes, in case of queue
merging. Then BFQ serves one bfq_queue at a time. While in service, a
bfq_queue is emptied in request-position order. Yet the same process,
or group of processes, may generate I/O for different actuators. In
this case, different streams of I/O (each for a different actuator)
get all inserted into the same sync bfq_queue. So there is basically
no individual control on when each stream is served, i.e., on when the
I/O requests of the stream are picked from the bfq_queue and
dispatched to the drive.
This commit enables BFQ to control the service of each actuator
individually for synchronous I/O, by simply splitting each sync
bfq_queue into N queues, one for each actuator. In other words, a sync
bfq_queue is now associated to a pair (process, actuator). As a
consequence of this split, the per-queue proportional-share policy
implemented by BFQ will guarantee that the sync I/O generated for each
actuator, by each process, receives its fair share of service.
This is just a preparatory patch. If the I/O of the same process
happens to be sent to different queues, then each of these queues may
undergo queue merging. To handle this event, the bfq_io_cq data
structure must be properly extended. In addition, stable merging must
be disabled to avoid loss of control on individual actuators. Finally,
also async queues must be split. These issues are described in detail
and addressed in next commits. As for this commit, although multiple
per-process bfq_queues are provided, the I/O of each process or group
of processes is still sent to only one queue, regardless of the
actuator the I/O is for. The forwarding to distinct bfq_queues will be
enabled after addressing the above issues.
[1] https://www.linaro.org/blog/budget-fair-queueing-bfq-linux-io-scheduler-optimizations-for-multi-actuator-sata-hard-drives/
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Gabriele Felici <felicigb@gmail.com>
Signed-off-by: Carmine Zaccagnino <carmine@carminezacc.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Link: https://lore.kernel.org/r/20230103145503.71712-2-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-03 14:54:56 +00:00
|
|
|
unsigned int act_idx;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
block, bfq: split sync bfq_queues on a per-actuator basis
Single-LUN multi-actuator SCSI drives, as well as all multi-actuator
SATA drives appear as a single device to the I/O subsystem [1]. Yet
they address commands to different actuators internally, as a function
of Logical Block Addressing (LBAs). A given sector is reachable by
only one of the actuators. For example, Seagate’s Serial Advanced
Technology Attachment (SATA) version contains two actuators and maps
the lower half of the SATA LBA space to the lower actuator and the
upper half to the upper actuator.
Evidently, to fully utilize actuators, no actuator must be left idle
or underutilized while there is pending I/O for it. The block layer
must somehow control the load of each actuator individually. This
commit lays the ground for allowing BFQ to provide such a per-actuator
control.
BFQ associates an I/O-request sync bfq_queue with each process doing
synchronous I/O, or with a group of processes, in case of queue
merging. Then BFQ serves one bfq_queue at a time. While in service, a
bfq_queue is emptied in request-position order. Yet the same process,
or group of processes, may generate I/O for different actuators. In
this case, different streams of I/O (each for a different actuator)
get all inserted into the same sync bfq_queue. So there is basically
no individual control on when each stream is served, i.e., on when the
I/O requests of the stream are picked from the bfq_queue and
dispatched to the drive.
This commit enables BFQ to control the service of each actuator
individually for synchronous I/O, by simply splitting each sync
bfq_queue into N queues, one for each actuator. In other words, a sync
bfq_queue is now associated to a pair (process, actuator). As a
consequence of this split, the per-queue proportional-share policy
implemented by BFQ will guarantee that the sync I/O generated for each
actuator, by each process, receives its fair share of service.
This is just a preparatory patch. If the I/O of the same process
happens to be sent to different queues, then each of these queues may
undergo queue merging. To handle this event, the bfq_io_cq data
structure must be properly extended. In addition, stable merging must
be disabled to avoid loss of control on individual actuators. Finally,
also async queues must be split. These issues are described in detail
and addressed in next commits. As for this commit, although multiple
per-process bfq_queues are provided, the I/O of each process or group
of processes is still sent to only one queue, regardless of the
actuator the I/O is for. The forwarding to distinct bfq_queues will be
enabled after addressing the above issues.
[1] https://www.linaro.org/blog/budget-fair-queueing-bfq-linux-io-scheduler-optimizations-for-multi-actuator-sata-hard-drives/
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Gabriele Felici <felicigb@gmail.com>
Signed-off-by: Carmine Zaccagnino <carmine@carminezacc.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Link: https://lore.kernel.org/r/20230103145503.71712-2-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-03 14:54:56 +00:00
|
|
|
for (act_idx = 0; act_idx < bfqd->num_actuators; act_idx++) {
|
|
|
|
struct bfq_queue *async_bfqq = bic_to_bfqq(bic, false, act_idx);
|
|
|
|
struct bfq_queue *sync_bfqq = bic_to_bfqq(bic, true, act_idx);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
block, bfq: split sync bfq_queues on a per-actuator basis
Single-LUN multi-actuator SCSI drives, as well as all multi-actuator
SATA drives appear as a single device to the I/O subsystem [1]. Yet
they address commands to different actuators internally, as a function
of Logical Block Addressing (LBAs). A given sector is reachable by
only one of the actuators. For example, Seagate’s Serial Advanced
Technology Attachment (SATA) version contains two actuators and maps
the lower half of the SATA LBA space to the lower actuator and the
upper half to the upper actuator.
Evidently, to fully utilize actuators, no actuator must be left idle
or underutilized while there is pending I/O for it. The block layer
must somehow control the load of each actuator individually. This
commit lays the ground for allowing BFQ to provide such a per-actuator
control.
BFQ associates an I/O-request sync bfq_queue with each process doing
synchronous I/O, or with a group of processes, in case of queue
merging. Then BFQ serves one bfq_queue at a time. While in service, a
bfq_queue is emptied in request-position order. Yet the same process,
or group of processes, may generate I/O for different actuators. In
this case, different streams of I/O (each for a different actuator)
get all inserted into the same sync bfq_queue. So there is basically
no individual control on when each stream is served, i.e., on when the
I/O requests of the stream are picked from the bfq_queue and
dispatched to the drive.
This commit enables BFQ to control the service of each actuator
individually for synchronous I/O, by simply splitting each sync
bfq_queue into N queues, one for each actuator. In other words, a sync
bfq_queue is now associated to a pair (process, actuator). As a
consequence of this split, the per-queue proportional-share policy
implemented by BFQ will guarantee that the sync I/O generated for each
actuator, by each process, receives its fair share of service.
This is just a preparatory patch. If the I/O of the same process
happens to be sent to different queues, then each of these queues may
undergo queue merging. To handle this event, the bfq_io_cq data
structure must be properly extended. In addition, stable merging must
be disabled to avoid loss of control on individual actuators. Finally,
also async queues must be split. These issues are described in detail
and addressed in next commits. As for this commit, although multiple
per-process bfq_queues are provided, the I/O of each process or group
of processes is still sent to only one queue, regardless of the
actuator the I/O is for. The forwarding to distinct bfq_queues will be
enabled after addressing the above issues.
[1] https://www.linaro.org/blog/budget-fair-queueing-bfq-linux-io-scheduler-optimizations-for-multi-actuator-sata-hard-drives/
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Gabriele Felici <felicigb@gmail.com>
Signed-off-by: Carmine Zaccagnino <carmine@carminezacc.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Link: https://lore.kernel.org/r/20230103145503.71712-2-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-03 14:54:56 +00:00
|
|
|
if (async_bfqq &&
|
|
|
|
async_bfqq->entity.sched_data != &bfqg->sched_data) {
|
|
|
|
bic_set_bfqq(bic, NULL, false, act_idx);
|
2020-03-21 09:45:19 +00:00
|
|
|
bfq_release_process_ref(bfqd, async_bfqq);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
block, bfq: split sync bfq_queues on a per-actuator basis
Single-LUN multi-actuator SCSI drives, as well as all multi-actuator
SATA drives appear as a single device to the I/O subsystem [1]. Yet
they address commands to different actuators internally, as a function
of Logical Block Addressing (LBAs). A given sector is reachable by
only one of the actuators. For example, Seagate’s Serial Advanced
Technology Attachment (SATA) version contains two actuators and maps
the lower half of the SATA LBA space to the lower actuator and the
upper half to the upper actuator.
Evidently, to fully utilize actuators, no actuator must be left idle
or underutilized while there is pending I/O for it. The block layer
must somehow control the load of each actuator individually. This
commit lays the ground for allowing BFQ to provide such a per-actuator
control.
BFQ associates an I/O-request sync bfq_queue with each process doing
synchronous I/O, or with a group of processes, in case of queue
merging. Then BFQ serves one bfq_queue at a time. While in service, a
bfq_queue is emptied in request-position order. Yet the same process,
or group of processes, may generate I/O for different actuators. In
this case, different streams of I/O (each for a different actuator)
get all inserted into the same sync bfq_queue. So there is basically
no individual control on when each stream is served, i.e., on when the
I/O requests of the stream are picked from the bfq_queue and
dispatched to the drive.
This commit enables BFQ to control the service of each actuator
individually for synchronous I/O, by simply splitting each sync
bfq_queue into N queues, one for each actuator. In other words, a sync
bfq_queue is now associated to a pair (process, actuator). As a
consequence of this split, the per-queue proportional-share policy
implemented by BFQ will guarantee that the sync I/O generated for each
actuator, by each process, receives its fair share of service.
This is just a preparatory patch. If the I/O of the same process
happens to be sent to different queues, then each of these queues may
undergo queue merging. To handle this event, the bfq_io_cq data
structure must be properly extended. In addition, stable merging must
be disabled to avoid loss of control on individual actuators. Finally,
also async queues must be split. These issues are described in detail
and addressed in next commits. As for this commit, although multiple
per-process bfq_queues are provided, the I/O of each process or group
of processes is still sent to only one queue, regardless of the
actuator the I/O is for. The forwarding to distinct bfq_queues will be
enabled after addressing the above issues.
[1] https://www.linaro.org/blog/budget-fair-queueing-bfq-linux-io-scheduler-optimizations-for-multi-actuator-sata-hard-drives/
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Gabriele Felici <felicigb@gmail.com>
Signed-off-by: Carmine Zaccagnino <carmine@carminezacc.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Link: https://lore.kernel.org/r/20230103145503.71712-2-paolo.valente@linaro.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-03 14:54:56 +00:00
|
|
|
if (sync_bfqq)
|
|
|
|
bfq_sync_bfqq_move(bfqd, sync_bfqq, bic, bfqg, act_idx);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfq_bic_update_cgroup(struct bfq_io_cq *bic, struct bio *bio)
|
|
|
|
{
|
|
|
|
struct bfq_data *bfqd = bic_to_bfqd(bic);
|
2022-04-01 10:27:49 +00:00
|
|
|
struct bfq_group *bfqg = bfq_bio_bfqg(bfqd, bio);
|
2017-04-19 14:48:24 +00:00
|
|
|
uint64_t serial_nr;
|
|
|
|
|
2022-04-01 10:27:49 +00:00
|
|
|
serial_nr = bfqg_to_blkg(bfqg)->blkcg->css.serial_nr;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether blkcg has changed. The condition may trigger
|
|
|
|
* spuriously on a newly created cic but there's no harm.
|
|
|
|
*/
|
|
|
|
if (unlikely(!bfqd) || likely(bic->blkcg_serial_nr == serial_nr))
|
2022-04-01 10:27:49 +00:00
|
|
|
return;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2022-04-01 10:27:49 +00:00
|
|
|
/*
|
|
|
|
* New cgroup for this process. Make sure it is linked to bfq internal
|
|
|
|
* cgroup hierarchy.
|
|
|
|
*/
|
|
|
|
bfq_link_bfqg(bfqd, bfqg);
|
|
|
|
__bfq_bic_change_cgroup(bfqd, bic, bfqg);
|
2017-04-19 14:48:24 +00:00
|
|
|
bic->blkcg_serial_nr = serial_nr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_flush_idle_tree - deactivate any entity on the idle tree of @st.
|
|
|
|
* @st: the service tree being flushed.
|
|
|
|
*/
|
|
|
|
static void bfq_flush_idle_tree(struct bfq_service_tree *st)
|
|
|
|
{
|
|
|
|
struct bfq_entity *entity = st->first_idle;
|
|
|
|
|
|
|
|
for (; entity ; entity = st->first_idle)
|
|
|
|
__bfq_deactivate_entity(entity, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_reparent_leaf_entity - move leaf entity to the root_group.
|
|
|
|
* @bfqd: the device data structure with the root group.
|
2020-03-21 09:45:20 +00:00
|
|
|
* @entity: the entity to move, if entity is a leaf; or the parent entity
|
|
|
|
* of an active leaf entity to move, if entity is not a leaf.
|
2022-06-17 21:08:59 +00:00
|
|
|
* @ioprio_class: I/O priority class to reparent.
|
2017-04-19 14:48:24 +00:00
|
|
|
*/
|
|
|
|
static void bfq_reparent_leaf_entity(struct bfq_data *bfqd,
|
2020-03-21 09:45:20 +00:00
|
|
|
struct bfq_entity *entity,
|
|
|
|
int ioprio_class)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
2020-03-21 09:45:20 +00:00
|
|
|
struct bfq_queue *bfqq;
|
|
|
|
struct bfq_entity *child_entity = entity;
|
|
|
|
|
|
|
|
while (child_entity->my_sched_data) { /* leaf not reached yet */
|
|
|
|
struct bfq_sched_data *child_sd = child_entity->my_sched_data;
|
|
|
|
struct bfq_service_tree *child_st = child_sd->service_tree +
|
|
|
|
ioprio_class;
|
|
|
|
struct rb_root *child_active = &child_st->active;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2020-03-21 09:45:20 +00:00
|
|
|
child_entity = bfq_entity_of(rb_first(child_active));
|
|
|
|
|
|
|
|
if (!child_entity)
|
|
|
|
child_entity = child_sd->in_service_entity;
|
|
|
|
}
|
|
|
|
|
|
|
|
bfqq = bfq_entity_to_bfqq(child_entity);
|
2017-04-19 14:48:24 +00:00
|
|
|
bfq_bfqq_move(bfqd, bfqq, bfqd->root_group);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-03-21 09:45:20 +00:00
|
|
|
* bfq_reparent_active_queues - move to the root group all active queues.
|
2017-04-19 14:48:24 +00:00
|
|
|
* @bfqd: the device data structure with the root group.
|
|
|
|
* @bfqg: the group to move from.
|
2020-03-21 09:45:20 +00:00
|
|
|
* @st: the service tree to start the search from.
|
2022-06-17 21:08:59 +00:00
|
|
|
* @ioprio_class: I/O priority class to reparent.
|
2017-04-19 14:48:24 +00:00
|
|
|
*/
|
2020-03-21 09:45:20 +00:00
|
|
|
static void bfq_reparent_active_queues(struct bfq_data *bfqd,
|
|
|
|
struct bfq_group *bfqg,
|
|
|
|
struct bfq_service_tree *st,
|
|
|
|
int ioprio_class)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct rb_root *active = &st->active;
|
2020-03-21 09:45:20 +00:00
|
|
|
struct bfq_entity *entity;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2020-03-21 09:45:20 +00:00
|
|
|
while ((entity = bfq_entity_of(rb_first(active))))
|
|
|
|
bfq_reparent_leaf_entity(bfqd, entity, ioprio_class);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
if (bfqg->sched_data.in_service_entity)
|
|
|
|
bfq_reparent_leaf_entity(bfqd,
|
2020-03-21 09:45:20 +00:00
|
|
|
bfqg->sched_data.in_service_entity,
|
|
|
|
ioprio_class);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bfq_pd_offline - deactivate the entity associated with @pd,
|
|
|
|
* and reparent its children entities.
|
|
|
|
* @pd: descriptor of the policy going offline.
|
|
|
|
*
|
|
|
|
* blkio already grabs the queue_lock for us, so no need to use
|
|
|
|
* RCU-based magic
|
|
|
|
*/
|
2017-08-30 18:42:08 +00:00
|
|
|
static void bfq_pd_offline(struct blkg_policy_data *pd)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct bfq_service_tree *st;
|
|
|
|
struct bfq_group *bfqg = pd_to_bfqg(pd);
|
|
|
|
struct bfq_data *bfqd = bfqg->bfqd;
|
|
|
|
struct bfq_entity *entity = bfqg->my_entity;
|
|
|
|
unsigned long flags;
|
|
|
|
int i;
|
|
|
|
|
block, bfq: put async queues for root bfq groups too
For each pair [device for which bfq is selected as I/O scheduler,
group in blkio/io], bfq maintains a corresponding bfq group. Each such
bfq group contains a set of async queues, with each async queue
created on demand, i.e., when some I/O request arrives for it. On
creation, an async queue gets an extra reference, to make sure that
the queue is not freed as long as its bfq group exists. Accordingly,
to allow the queue to be freed after the group exited, this extra
reference must released on group exit.
The above holds also for a bfq root group, i.e., for the bfq group
corresponding to the root blkio/io root for a given device. Yet, by
mistake, the references to the existing async queues of a root group
are not released when the latter exits. This causes a memory leak when
the instance of bfq for a given device exits. In a similar vein,
bfqg_stats_xfer_dead is not executed for a root group.
This commit fixes bfq_pd_offline so that the latter executes the above
missing operations for a root group too.
Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Reported-by: Guoqing Jiang <gqjiang@suse.com>
Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Signed-off-by: Davide Ferrari <davideferrari8@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-01-09 09:27:58 +00:00
|
|
|
spin_lock_irqsave(&bfqd->lock, flags);
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
if (!entity) /* root group */
|
block, bfq: put async queues for root bfq groups too
For each pair [device for which bfq is selected as I/O scheduler,
group in blkio/io], bfq maintains a corresponding bfq group. Each such
bfq group contains a set of async queues, with each async queue
created on demand, i.e., when some I/O request arrives for it. On
creation, an async queue gets an extra reference, to make sure that
the queue is not freed as long as its bfq group exists. Accordingly,
to allow the queue to be freed after the group exited, this extra
reference must released on group exit.
The above holds also for a bfq root group, i.e., for the bfq group
corresponding to the root blkio/io root for a given device. Yet, by
mistake, the references to the existing async queues of a root group
are not released when the latter exits. This causes a memory leak when
the instance of bfq for a given device exits. In a similar vein,
bfqg_stats_xfer_dead is not executed for a root group.
This commit fixes bfq_pd_offline so that the latter executes the above
missing operations for a root group too.
Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Reported-by: Guoqing Jiang <gqjiang@suse.com>
Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Signed-off-by: Davide Ferrari <davideferrari8@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-01-09 09:27:58 +00:00
|
|
|
goto put_async_queues;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Empty all service_trees belonging to this group before
|
|
|
|
* deactivating the group itself.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < BFQ_IOPRIO_CLASSES; i++) {
|
|
|
|
st = bfqg->sched_data.service_tree + i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It may happen that some queues are still active
|
|
|
|
* (busy) upon group destruction (if the corresponding
|
|
|
|
* processes have been forced to terminate). We move
|
|
|
|
* all the leaf entities corresponding to these queues
|
|
|
|
* to the root_group.
|
|
|
|
* Also, it may happen that the group has an entity
|
|
|
|
* in service, which is disconnected from the active
|
|
|
|
* tree: it must be moved, too.
|
|
|
|
* There is no need to put the sync queues, as the
|
|
|
|
* scheduler has taken no reference.
|
|
|
|
*/
|
2020-03-21 09:45:20 +00:00
|
|
|
bfq_reparent_active_queues(bfqd, bfqg, st, i);
|
2020-03-21 09:45:21 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The idle tree may still contain bfq_queues
|
|
|
|
* belonging to exited task because they never
|
|
|
|
* migrated to a different cgroup from the one being
|
|
|
|
* destroyed now. In addition, even
|
|
|
|
* bfq_reparent_active_queues() may happen to add some
|
|
|
|
* entities to the idle tree. It happens if, in some
|
|
|
|
* of the calls to bfq_bfqq_move() performed by
|
|
|
|
* bfq_reparent_active_queues(), the queue to move is
|
|
|
|
* empty and gets expired.
|
|
|
|
*/
|
|
|
|
bfq_flush_idle_tree(st);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
__bfq_deactivate_entity(entity, false);
|
block, bfq: put async queues for root bfq groups too
For each pair [device for which bfq is selected as I/O scheduler,
group in blkio/io], bfq maintains a corresponding bfq group. Each such
bfq group contains a set of async queues, with each async queue
created on demand, i.e., when some I/O request arrives for it. On
creation, an async queue gets an extra reference, to make sure that
the queue is not freed as long as its bfq group exists. Accordingly,
to allow the queue to be freed after the group exited, this extra
reference must released on group exit.
The above holds also for a bfq root group, i.e., for the bfq group
corresponding to the root blkio/io root for a given device. Yet, by
mistake, the references to the existing async queues of a root group
are not released when the latter exits. This causes a memory leak when
the instance of bfq for a given device exits. In a similar vein,
bfqg_stats_xfer_dead is not executed for a root group.
This commit fixes bfq_pd_offline so that the latter executes the above
missing operations for a root group too.
Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Reported-by: Guoqing Jiang <gqjiang@suse.com>
Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Signed-off-by: Davide Ferrari <davideferrari8@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-01-09 09:27:58 +00:00
|
|
|
|
|
|
|
put_async_queues:
|
2017-04-19 14:48:24 +00:00
|
|
|
bfq_put_async_queues(bfqd, bfqg);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&bfqd->lock, flags);
|
|
|
|
/*
|
|
|
|
* @blkg is going offline and will be ignored by
|
|
|
|
* blkg_[rw]stat_recursive_sum(). Transfer stats to the parent so
|
|
|
|
* that they don't get lost. If IOs complete after this point, the
|
|
|
|
* stats for them will be lost. Oh well...
|
|
|
|
*/
|
|
|
|
bfqg_stats_xfer_dead(bfqg);
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfq_end_wr_async(struct bfq_data *bfqd)
|
|
|
|
{
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
|
|
|
|
list_for_each_entry(blkg, &bfqd->queue->blkg_list, q_node) {
|
|
|
|
struct bfq_group *bfqg = blkg_to_bfqg(blkg);
|
|
|
|
|
|
|
|
bfq_end_wr_async_queues(bfqd, bfqg);
|
|
|
|
}
|
|
|
|
bfq_end_wr_async_queues(bfqd, bfqd->root_group);
|
|
|
|
}
|
|
|
|
|
2019-08-28 03:54:53 +00:00
|
|
|
static int bfq_io_show_weight_legacy(struct seq_file *sf, void *v)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
struct blkcg *blkcg = css_to_blkcg(seq_css(sf));
|
|
|
|
struct bfq_group_data *bfqgd = blkcg_to_bfqgd(blkcg);
|
|
|
|
unsigned int val = 0;
|
|
|
|
|
|
|
|
if (bfqgd)
|
|
|
|
val = bfqgd->weight;
|
|
|
|
|
|
|
|
seq_printf(sf, "%u\n", val);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-08-28 03:54:53 +00:00
|
|
|
static u64 bfqg_prfill_weight_device(struct seq_file *sf,
|
|
|
|
struct blkg_policy_data *pd, int off)
|
2019-08-28 03:54:52 +00:00
|
|
|
{
|
2019-08-28 03:54:53 +00:00
|
|
|
struct bfq_group *bfqg = pd_to_bfqg(pd);
|
|
|
|
|
|
|
|
if (!bfqg->entity.dev_weight)
|
|
|
|
return 0;
|
|
|
|
return __blkg_prfill_u64(sf, pd, bfqg->entity.dev_weight);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int bfq_io_show_weight(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
struct blkcg *blkcg = css_to_blkcg(seq_css(sf));
|
|
|
|
struct bfq_group_data *bfqgd = blkcg_to_bfqgd(blkcg);
|
|
|
|
|
|
|
|
seq_printf(sf, "default %u\n", bfqgd->weight);
|
|
|
|
blkcg_print_blkgs(sf, blkcg, bfqg_prfill_weight_device,
|
|
|
|
&blkcg_policy_bfq, 0, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void bfq_group_set_weight(struct bfq_group *bfqg, u64 weight, u64 dev_weight)
|
|
|
|
{
|
|
|
|
weight = dev_weight ?: weight;
|
|
|
|
|
|
|
|
bfqg->entity.dev_weight = dev_weight;
|
2019-08-28 03:54:52 +00:00
|
|
|
/*
|
|
|
|
* Setting the prio_changed flag of the entity
|
|
|
|
* to 1 with new_weight == weight would re-set
|
|
|
|
* the value of the weight to its ioprio mapping.
|
|
|
|
* Set the flag only if necessary.
|
|
|
|
*/
|
|
|
|
if ((unsigned short)weight != bfqg->entity.new_weight) {
|
|
|
|
bfqg->entity.new_weight = (unsigned short)weight;
|
|
|
|
/*
|
|
|
|
* Make sure that the above new value has been
|
|
|
|
* stored in bfqg->entity.new_weight before
|
|
|
|
* setting the prio_changed flag. In fact,
|
|
|
|
* this flag may be read asynchronously (in
|
|
|
|
* critical sections protected by a different
|
|
|
|
* lock than that held here), and finding this
|
|
|
|
* flag set may cause the execution of the code
|
|
|
|
* for updating parameters whose value may
|
|
|
|
* depend also on bfqg->entity.new_weight (in
|
|
|
|
* __bfq_entity_update_weight_prio).
|
|
|
|
* This barrier makes sure that the new value
|
|
|
|
* of bfqg->entity.new_weight is correctly
|
|
|
|
* seen in that code.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
bfqg->entity.prio_changed = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
static int bfq_io_set_weight_legacy(struct cgroup_subsys_state *css,
|
|
|
|
struct cftype *cftype,
|
|
|
|
u64 val)
|
|
|
|
{
|
|
|
|
struct blkcg *blkcg = css_to_blkcg(css);
|
|
|
|
struct bfq_group_data *bfqgd = blkcg_to_bfqgd(blkcg);
|
|
|
|
struct blkcg_gq *blkg;
|
|
|
|
int ret = -ERANGE;
|
|
|
|
|
|
|
|
if (val < BFQ_MIN_WEIGHT || val > BFQ_MAX_WEIGHT)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
spin_lock_irq(&blkcg->lock);
|
|
|
|
bfqgd->weight = (unsigned short)val;
|
|
|
|
hlist_for_each_entry(blkg, &blkcg->blkg_list, blkcg_node) {
|
|
|
|
struct bfq_group *bfqg = blkg_to_bfqg(blkg);
|
|
|
|
|
2019-08-28 03:54:52 +00:00
|
|
|
if (bfqg)
|
2019-08-28 03:54:53 +00:00
|
|
|
bfq_group_set_weight(bfqg, val, 0);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
spin_unlock_irq(&blkcg->lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-08-28 03:54:53 +00:00
|
|
|
static ssize_t bfq_io_set_device_weight(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes,
|
|
|
|
loff_t off)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
2019-08-28 03:54:53 +00:00
|
|
|
int ret;
|
|
|
|
struct blkg_conf_ctx ctx;
|
|
|
|
struct blkcg *blkcg = css_to_blkcg(of_css(of));
|
|
|
|
struct bfq_group *bfqg;
|
|
|
|
u64 v;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2023-04-13 00:06:47 +00:00
|
|
|
blkg_conf_init(&ctx, buf);
|
|
|
|
|
|
|
|
ret = blkg_conf_prep(blkcg, &blkcg_policy_bfq, &ctx);
|
2017-04-19 14:48:24 +00:00
|
|
|
if (ret)
|
2023-04-13 00:06:47 +00:00
|
|
|
goto out;
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2019-08-28 03:54:53 +00:00
|
|
|
if (sscanf(ctx.body, "%llu", &v) == 1) {
|
|
|
|
/* require "default" on dfl */
|
|
|
|
ret = -ERANGE;
|
|
|
|
if (!v)
|
|
|
|
goto out;
|
|
|
|
} else if (!strcmp(strim(ctx.body), "default")) {
|
|
|
|
v = 0;
|
|
|
|
} else {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
bfqg = blkg_to_bfqg(ctx.blkg);
|
|
|
|
|
|
|
|
ret = -ERANGE;
|
|
|
|
if (!v || (v >= BFQ_MIN_WEIGHT && v <= BFQ_MAX_WEIGHT)) {
|
|
|
|
bfq_group_set_weight(bfqg, bfqg->entity.weight, v);
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
out:
|
2023-04-13 00:06:47 +00:00
|
|
|
blkg_conf_exit(&ctx);
|
2018-08-15 21:56:45 +00:00
|
|
|
return ret ?: nbytes;
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
2019-08-28 03:54:53 +00:00
|
|
|
static ssize_t bfq_io_set_weight(struct kernfs_open_file *of,
|
|
|
|
char *buf, size_t nbytes,
|
|
|
|
loff_t off)
|
|
|
|
{
|
|
|
|
char *endp;
|
|
|
|
int ret;
|
|
|
|
u64 v;
|
|
|
|
|
|
|
|
buf = strim(buf);
|
|
|
|
|
|
|
|
/* "WEIGHT" or "default WEIGHT" sets the default weight */
|
|
|
|
v = simple_strtoull(buf, &endp, 0);
|
|
|
|
if (*endp == '\0' || sscanf(buf, "default %llu", &v) == 1) {
|
|
|
|
ret = bfq_io_set_weight_legacy(of_css(of), NULL, v);
|
|
|
|
return ret ?: nbytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
return bfq_io_set_device_weight(of, buf, nbytes, off);
|
|
|
|
}
|
|
|
|
|
2019-11-07 19:17:59 +00:00
|
|
|
static int bfqg_print_rwstat(struct seq_file *sf, void *v)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
2019-11-07 19:17:59 +00:00
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), blkg_prfill_rwstat,
|
|
|
|
&blkcg_policy_bfq, seq_cft(sf)->private, true);
|
2017-04-19 14:48:24 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-11-07 19:17:59 +00:00
|
|
|
static u64 bfqg_prfill_rwstat_recursive(struct seq_file *sf,
|
|
|
|
struct blkg_policy_data *pd, int off)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
2019-11-07 19:17:59 +00:00
|
|
|
struct blkg_rwstat_sample sum;
|
|
|
|
|
|
|
|
blkg_rwstat_recursive_sum(pd_to_blkg(pd), &blkcg_policy_bfq, off, &sum);
|
|
|
|
return __blkg_prfill_rwstat(sf, pd, &sum);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int bfqg_print_rwstat_recursive(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
bfqg_prfill_rwstat_recursive, &blkcg_policy_bfq,
|
|
|
|
seq_cft(sf)->private, true);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-11-07 19:18:00 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
2019-11-07 19:17:59 +00:00
|
|
|
static int bfqg_print_stat(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), blkg_prfill_stat,
|
|
|
|
&blkcg_policy_bfq, seq_cft(sf)->private, false);
|
2017-04-19 14:48:24 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 bfqg_prfill_stat_recursive(struct seq_file *sf,
|
|
|
|
struct blkg_policy_data *pd, int off)
|
|
|
|
{
|
2019-06-06 10:26:23 +00:00
|
|
|
struct blkcg_gq *blkg = pd_to_blkg(pd);
|
|
|
|
struct blkcg_gq *pos_blkg;
|
|
|
|
struct cgroup_subsys_state *pos_css;
|
|
|
|
u64 sum = 0;
|
|
|
|
|
|
|
|
lockdep_assert_held(&blkg->q->queue_lock);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
blkg_for_each_descendant_pre(pos_blkg, pos_css, blkg) {
|
|
|
|
struct bfq_stat *stat;
|
|
|
|
|
|
|
|
if (!pos_blkg->online)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
stat = (void *)blkg_to_pd(pos_blkg, &blkcg_policy_bfq) + off;
|
|
|
|
sum += bfq_stat_read(stat) + atomic64_read(&stat->aux_cnt);
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
return __blkg_prfill_u64(sf, pd, sum);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int bfqg_print_stat_recursive(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
bfqg_prfill_stat_recursive, &blkcg_policy_bfq,
|
|
|
|
seq_cft(sf)->private, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 bfqg_prfill_sectors(struct seq_file *sf, struct blkg_policy_data *pd,
|
|
|
|
int off)
|
|
|
|
{
|
2019-11-07 19:18:00 +00:00
|
|
|
struct bfq_group *bfqg = blkg_to_bfqg(pd->blkg);
|
|
|
|
u64 sum = blkg_rwstat_total(&bfqg->stats.bytes);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
return __blkg_prfill_u64(sf, pd, sum >> 9);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int bfqg_print_stat_sectors(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
bfqg_prfill_sectors, &blkcg_policy_bfq, 0, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 bfqg_prfill_sectors_recursive(struct seq_file *sf,
|
|
|
|
struct blkg_policy_data *pd, int off)
|
|
|
|
{
|
2019-06-06 10:26:21 +00:00
|
|
|
struct blkg_rwstat_sample tmp;
|
2019-06-06 10:26:20 +00:00
|
|
|
|
2019-11-07 19:18:00 +00:00
|
|
|
blkg_rwstat_recursive_sum(pd->blkg, &blkcg_policy_bfq,
|
|
|
|
offsetof(struct bfq_group, stats.bytes), &tmp);
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2019-06-06 10:26:21 +00:00
|
|
|
return __blkg_prfill_u64(sf, pd,
|
|
|
|
(tmp.cnt[BLKG_RWSTAT_READ] + tmp.cnt[BLKG_RWSTAT_WRITE]) >> 9);
|
2017-04-19 14:48:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int bfqg_print_stat_sectors_recursive(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
bfqg_prfill_sectors_recursive, &blkcg_policy_bfq, 0,
|
|
|
|
false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 bfqg_prfill_avg_queue_size(struct seq_file *sf,
|
|
|
|
struct blkg_policy_data *pd, int off)
|
|
|
|
{
|
|
|
|
struct bfq_group *bfqg = pd_to_bfqg(pd);
|
2019-06-06 10:26:22 +00:00
|
|
|
u64 samples = bfq_stat_read(&bfqg->stats.avg_queue_size_samples);
|
2017-04-19 14:48:24 +00:00
|
|
|
u64 v = 0;
|
|
|
|
|
|
|
|
if (samples) {
|
2019-06-06 10:26:22 +00:00
|
|
|
v = bfq_stat_read(&bfqg->stats.avg_queue_size_sum);
|
2017-04-19 14:48:24 +00:00
|
|
|
v = div64_u64(v, samples);
|
|
|
|
}
|
|
|
|
__blkg_prfill_u64(sf, pd, v);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* print avg_queue_size */
|
|
|
|
static int bfqg_print_avg_queue_size(struct seq_file *sf, void *v)
|
|
|
|
{
|
|
|
|
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)),
|
|
|
|
bfqg_prfill_avg_queue_size, &blkcg_policy_bfq,
|
|
|
|
0, false);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-06-06 10:26:24 +00:00
|
|
|
#endif /* CONFIG_BFQ_CGROUP_DEBUG */
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
struct bfq_group *bfq_create_group_hierarchy(struct bfq_data *bfqd, int node)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2023-02-03 15:03:57 +00:00
|
|
|
ret = blkcg_activate_policy(bfqd->queue->disk, &blkcg_policy_bfq);
|
2017-04-19 14:48:24 +00:00
|
|
|
if (ret)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return blkg_to_bfqg(bfqd->queue->root_blkg);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct blkcg_policy blkcg_policy_bfq = {
|
|
|
|
.dfl_cftypes = bfq_blkg_files,
|
|
|
|
.legacy_cftypes = bfq_blkcg_legacy_files,
|
|
|
|
|
|
|
|
.cpd_alloc_fn = bfq_cpd_alloc,
|
|
|
|
.cpd_free_fn = bfq_cpd_free,
|
|
|
|
|
|
|
|
.pd_alloc_fn = bfq_pd_alloc,
|
|
|
|
.pd_init_fn = bfq_pd_init,
|
|
|
|
.pd_offline_fn = bfq_pd_offline,
|
|
|
|
.pd_free_fn = bfq_pd_free,
|
|
|
|
.pd_reset_stats_fn = bfq_pd_reset_stats,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct cftype bfq_blkcg_legacy_files[] = {
|
|
|
|
{
|
|
|
|
.name = "bfq.weight",
|
2019-06-10 09:35:41 +00:00
|
|
|
.flags = CFTYPE_NOT_ON_ROOT,
|
2019-08-28 03:54:53 +00:00
|
|
|
.seq_show = bfq_io_show_weight_legacy,
|
2017-04-19 14:48:24 +00:00
|
|
|
.write_u64 = bfq_io_set_weight_legacy,
|
|
|
|
},
|
2019-08-28 03:54:53 +00:00
|
|
|
{
|
|
|
|
.name = "bfq.weight_device",
|
|
|
|
.flags = CFTYPE_NOT_ON_ROOT,
|
|
|
|
.seq_show = bfq_io_show_weight,
|
|
|
|
.write = bfq_io_set_weight,
|
|
|
|
},
|
2017-04-19 14:48:24 +00:00
|
|
|
|
|
|
|
/* statistics, covers only the tasks in the bfqg */
|
|
|
|
{
|
|
|
|
.name = "bfq.io_service_bytes",
|
2019-11-07 19:18:00 +00:00
|
|
|
.private = offsetof(struct bfq_group, stats.bytes),
|
|
|
|
.seq_show = bfqg_print_rwstat,
|
2017-04-19 14:48:24 +00:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_serviced",
|
2019-11-07 19:18:00 +00:00
|
|
|
.private = offsetof(struct bfq_group, stats.ios),
|
|
|
|
.seq_show = bfqg_print_rwstat,
|
2017-04-19 14:48:24 +00:00
|
|
|
},
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
{
|
|
|
|
.name = "bfq.time",
|
|
|
|
.private = offsetof(struct bfq_group, stats.time),
|
|
|
|
.seq_show = bfqg_print_stat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.sectors",
|
|
|
|
.seq_show = bfqg_print_stat_sectors,
|
|
|
|
},
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
.name = "bfq.io_service_time",
|
|
|
|
.private = offsetof(struct bfq_group, stats.service_time),
|
|
|
|
.seq_show = bfqg_print_rwstat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_wait_time",
|
|
|
|
.private = offsetof(struct bfq_group, stats.wait_time),
|
|
|
|
.seq_show = bfqg_print_rwstat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_merged",
|
|
|
|
.private = offsetof(struct bfq_group, stats.merged),
|
|
|
|
.seq_show = bfqg_print_rwstat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_queued",
|
|
|
|
.private = offsetof(struct bfq_group, stats.queued),
|
|
|
|
.seq_show = bfqg_print_rwstat,
|
|
|
|
},
|
2019-06-06 10:26:24 +00:00
|
|
|
#endif /* CONFIG_BFQ_CGROUP_DEBUG */
|
2017-04-19 14:48:24 +00:00
|
|
|
|
2019-04-08 15:35:34 +00:00
|
|
|
/* the same statistics which cover the bfqg and its descendants */
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
.name = "bfq.io_service_bytes_recursive",
|
2019-11-07 19:18:00 +00:00
|
|
|
.private = offsetof(struct bfq_group, stats.bytes),
|
|
|
|
.seq_show = bfqg_print_rwstat_recursive,
|
2017-04-19 14:48:24 +00:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_serviced_recursive",
|
2019-11-07 19:18:00 +00:00
|
|
|
.private = offsetof(struct bfq_group, stats.ios),
|
|
|
|
.seq_show = bfqg_print_rwstat_recursive,
|
2017-04-19 14:48:24 +00:00
|
|
|
},
|
2019-06-06 10:26:24 +00:00
|
|
|
#ifdef CONFIG_BFQ_CGROUP_DEBUG
|
block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP
BFQ currently creates, and updates, its own instance of the whole
set of blkio statistics that cfq creates. Yet, from the comments
of Tejun Heo in [1], it turned out that most of these statistics
are meant/useful only for debugging. This commit makes BFQ create
the latter, debugging statistics only if the option
CONFIG_DEBUG_BLK_CGROUP is set.
By doing so, this commit also enables BFQ to enjoy a high perfomance
boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then
BFQ has to update far fewer statistics, and, in particular, not the
heaviest to update. To give an idea of the benefits, if
CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and
with 8 threads doing random I/O in parallel on null_blk (configured
with 0 latency), the throughput of BFQ grows from 310 to 400 KIOPS
(+30%). We have measured similar or even much higher boosts with other
CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have
been obtained and can be reproduced very easily with the script in [1].
[1] https://www.spinics.net/lists/linux-block/msg18943.html
Suggested-by: Tejun Heo <tj@kernel.org>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Lee Tibbert <lee.tibbert@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-13 06:34:10 +00:00
|
|
|
{
|
|
|
|
.name = "bfq.time_recursive",
|
|
|
|
.private = offsetof(struct bfq_group, stats.time),
|
|
|
|
.seq_show = bfqg_print_stat_recursive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.sectors_recursive",
|
|
|
|
.seq_show = bfqg_print_stat_sectors_recursive,
|
|
|
|
},
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
.name = "bfq.io_service_time_recursive",
|
|
|
|
.private = offsetof(struct bfq_group, stats.service_time),
|
|
|
|
.seq_show = bfqg_print_rwstat_recursive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_wait_time_recursive",
|
|
|
|
.private = offsetof(struct bfq_group, stats.wait_time),
|
|
|
|
.seq_show = bfqg_print_rwstat_recursive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_merged_recursive",
|
|
|
|
.private = offsetof(struct bfq_group, stats.merged),
|
|
|
|
.seq_show = bfqg_print_rwstat_recursive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.io_queued_recursive",
|
|
|
|
.private = offsetof(struct bfq_group, stats.queued),
|
|
|
|
.seq_show = bfqg_print_rwstat_recursive,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.avg_queue_size",
|
|
|
|
.seq_show = bfqg_print_avg_queue_size,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.group_wait_time",
|
|
|
|
.private = offsetof(struct bfq_group, stats.group_wait_time),
|
|
|
|
.seq_show = bfqg_print_stat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.idle_time",
|
|
|
|
.private = offsetof(struct bfq_group, stats.idle_time),
|
|
|
|
.seq_show = bfqg_print_stat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.empty_time",
|
|
|
|
.private = offsetof(struct bfq_group, stats.empty_time),
|
|
|
|
.seq_show = bfqg_print_stat,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "bfq.dequeue",
|
|
|
|
.private = offsetof(struct bfq_group, stats.dequeue),
|
|
|
|
.seq_show = bfqg_print_stat,
|
|
|
|
},
|
2019-06-06 10:26:24 +00:00
|
|
|
#endif /* CONFIG_BFQ_CGROUP_DEBUG */
|
2017-04-19 14:48:24 +00:00
|
|
|
{ } /* terminate */
|
|
|
|
};
|
|
|
|
|
|
|
|
struct cftype bfq_blkg_files[] = {
|
|
|
|
{
|
|
|
|
.name = "bfq.weight",
|
2019-06-10 09:35:41 +00:00
|
|
|
.flags = CFTYPE_NOT_ON_ROOT,
|
2017-04-19 14:48:24 +00:00
|
|
|
.seq_show = bfq_io_show_weight,
|
|
|
|
.write = bfq_io_set_weight,
|
|
|
|
},
|
|
|
|
{} /* terminate */
|
|
|
|
};
|
|
|
|
|
|
|
|
#else /* CONFIG_BFQ_GROUP_IOSCHED */
|
|
|
|
|
|
|
|
void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
|
|
|
|
struct bfq_group *bfqg) {}
|
|
|
|
|
|
|
|
void bfq_init_entity(struct bfq_entity *entity, struct bfq_group *bfqg)
|
|
|
|
{
|
|
|
|
struct bfq_queue *bfqq = bfq_entity_to_bfqq(entity);
|
|
|
|
|
|
|
|
entity->weight = entity->new_weight;
|
|
|
|
entity->orig_weight = entity->new_weight;
|
|
|
|
if (bfqq) {
|
|
|
|
bfqq->ioprio = bfqq->new_ioprio;
|
|
|
|
bfqq->ioprio_class = bfqq->new_ioprio_class;
|
|
|
|
}
|
|
|
|
entity->sched_data = &bfqg->sched_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
void bfq_bic_update_cgroup(struct bfq_io_cq *bic, struct bio *bio) {}
|
|
|
|
|
|
|
|
void bfq_end_wr_async(struct bfq_data *bfqd)
|
|
|
|
{
|
|
|
|
bfq_end_wr_async_queues(bfqd, bfqd->root_group);
|
|
|
|
}
|
|
|
|
|
2022-04-01 10:27:49 +00:00
|
|
|
struct bfq_group *bfq_bio_bfqg(struct bfq_data *bfqd, struct bio *bio)
|
2017-04-19 14:48:24 +00:00
|
|
|
{
|
|
|
|
return bfqd->root_group;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct bfq_group *bfqq_group(struct bfq_queue *bfqq)
|
|
|
|
{
|
|
|
|
return bfqq->bfqd->root_group;
|
|
|
|
}
|
|
|
|
|
2020-02-03 10:40:58 +00:00
|
|
|
void bfqg_and_blkg_put(struct bfq_group *bfqg) {}
|
|
|
|
|
2017-04-19 14:48:24 +00:00
|
|
|
struct bfq_group *bfq_create_group_hierarchy(struct bfq_data *bfqd, int node)
|
|
|
|
{
|
|
|
|
struct bfq_group *bfqg;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
bfqg = kmalloc_node(sizeof(*bfqg), GFP_KERNEL | __GFP_ZERO, node);
|
|
|
|
if (!bfqg)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
for (i = 0; i < BFQ_IOPRIO_CLASSES; i++)
|
|
|
|
bfqg->sched_data.service_tree[i] = BFQ_SERVICE_TREE_INIT;
|
|
|
|
|
|
|
|
return bfqg;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_BFQ_GROUP_IOSCHED */
|