• P
    block, bfq: let a queue be merged only shortly after starting I/O · 7b8fa3b9
    Paolo Valente 提交于
    In BFQ and CFQ, two processes are said to be cooperating if they do
    I/O in such a way that the union of their I/O requests yields a
    sequential I/O pattern. To get such a sequential I/O pattern out of
    the non-sequential pattern of each cooperating process, BFQ and CFQ
    merge the queues associated with these processes. In more detail,
    cooperating processes, and thus their associated queues, usually
    start, or restart, to do I/O shortly after each other. This is the
    case, e.g., for the I/O threads of KVM/QEMU and of the dump
    utility. Basing on this assumption, this commit allows a bfq_queue to
    be merged only during a short time interval (100ms) after it starts,
    or re-starts, to do I/O.  This filtering provides two important
    benefits.
    
    First, it greatly reduces the probability that two non-cooperating
    processes have their queues merged by mistake, if they just happen to
    do I/O close to each other for a short time interval. These spurious
    merges cause loss of service guarantees. A low-weight bfq_queue may
    unjustly get more than its expected share of the throughput: if such a
    low-weight queue is merged with a high-weight queue, then the I/O for
    the low-weight queue is served as if the queue had a high weight. This
    may damage other high-weight queues unexpectedly.  For instance,
    because of this issue, lxterminal occasionally took 7.5 seconds to
    start, instead of 6.5 seconds, when some sequential readers and
    writers did I/O in the background on a FUJITSU MHX2300BT HDD.  The
    reason is that the bfq_queues associated with some of the readers or
    the writers were merged with the high-weight queues of some processes
    that had to do some urgent but little I/O. The readers then exploited
    the inherited high weight for all or most of their I/O, during the
    start-up of terminal. The filtering introduced by this commit
    eliminated any outlier caused by spurious queue merges in our start-up
    time tests.
    
    This filtering also provides a little boost of the throughput
    sustainable by BFQ: 3-4%, depending on the CPU. The reason is that,
    once a bfq_queue cannot be merged any longer, this commit makes BFQ
    stop updating the data needed to handle merging for the queue.
    Signed-off-by: NPaolo Valente <paolo.valente@linaro.org>
    Signed-off-by: NAngelo Ruocco <angeloruocco90@gmail.com>
    Signed-off-by: NJens Axboe <axboe@kernel.dk>
    7b8fa3b9
bfq-iosched.h 31.5 KB