diff options
| author | Paolo Valente <[email protected]> | 2017-09-21 11:04:02 +0200 |
|---|---|---|
| committer | Jens Axboe <[email protected]> | 2017-10-03 08:40:57 -0600 |
| commit | 894df937e06a56ed6f054a75a416aff84147c5a2 (patch) | |
| tree | 2ef0faa82b5c62b30ce98136e8e9efe506a4d054 /tools/perf/scripts/python/event_analyzing_sample.py | |
| parent | 3e2bdd6dff239afd8386e8758eee69ad61e5a3d6 (diff) | |
block, bfq: let early-merged queues be weight-raised on split too
A just-created bfq_queue, say Q, may happen to be merged with another
bfq_queue on the very first invocation of the function
__bfq_insert_request. In such a case, even if Q would clearly deserve
interactive weight raising (as it has just been created), the function
bfq_add_request does not make it to be invoked for Q, and thus to
activate weight raising for Q. As a consequence, when the state of Q
is saved for a possible future restore, after a split of Q from the
other bfq_queue(s), such a state happens to be (unjustly)
non-weight-raised. Then the bfq_queue will not enjoy any weight
raising on the split, even if should still be in an interactive
weight-raising period when the split occurs.
This commit solves this problem as follows, for a just-created
bfq_queue that is being early-merged: it stores directly, in the saved
state of the bfq_queue, the weight-raising state that would have been
assigned to the bfq_queue if not early-merged.
Signed-off-by: Paolo Valente <[email protected]>
Tested-by: Angelo Ruocco <[email protected]>
Tested-by: Mirko Montanari <[email protected]>
Tested-by: Oleksandr Natalenko <[email protected]>
Tested-by: Lee Tibbert <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/event_analyzing_sample.py')
0 files changed, 0 insertions, 0 deletions