lkml.org 
[lkml]   [2008]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: RFC: I/O bandwidth controller
    From
    Hi, Naveen,

    > > If we are pursuing a I/O prioritization model à la CFQ the temptation is
    > > to implement it at the elevator layer or extend any of the existing I/O
    > > schedulers.
    > >
    > > There have been several proposals that extend either the CFQ scheduler
    > > (see (1), (2) below) or the AS scheduler (see (3) below). The problem
    > > with these controllers is that they are scheduler dependent, which means
    > > that they become unusable when we change the scheduler or when we want
    > > to control stacking devices which define their own make_request_fn
    > > function (md and dm come to mind). It could be argued that the physical
    > > devices controlled by a dm or md driver are likely to be fed by
    > > traditional I/O schedulers such as CFQ, but these I/O schedulers would
    > > be running independently from each other, each one controlling its own
    > > device ignoring the fact that they part of a stacking device. This lack
    > > of information at the elevator layer makes it pretty difficult to obtain
    > > accurate results when using stacking devices. It seems that unless we
    > > can make the elevator layer aware of the topology of stacking devices
    > > (possibly by extending the elevator API?) evelator-based approaches do
    > > not constitute a generic solution. Here onwards, for discussion
    > > purposes, I will refer to this type of I/O bandwidth controllers as
    > > elevator-based I/O controllers.
    >
    > It can be argued that any scheduling decision wrt to i/o belongs to
    > elevators. Till now they have been used to improve performance. But
    > with new requirements to isolate i/o based on process or cgroup, we
    > need to change the elevators.
    >
    > If we add another layer of i/o scheduling (block layer I/O controller)
    > above elevators
    > 1) It builds another layer of i/o scheduling (bandwidth or priority)
    > 2) This new layer can have decisions for i/o scheduling which conflict
    > with underlying elevator. e.g. If we decide to do b/w scheduling in
    > this new layer, there is no way a priority based elevator could work
    > underneath it.

    I seems like the same goes for the current Linux kernel implementation
    that if processes issued a lot of I/O requests and the io-request queue
    of a disk is overflowed, all the I/O requests after will be blocked
    and the priorities of them are meaningless.
    In other word, it won't work if it receives lots of requests more than
    the ability/bandwidth of a disk.

    It doesn't seem so weird if it won't work if a cgroup issues lots of
    I/O requests more than the bandwidth which is assigned to the cgroup.

    > If a custom make_request_fn is defined (which means the said device is
    > not using existing elevator), it could build it's own scheduling
    > rather than asking kernel to add another layer at the time of i/o
    > submission. Since it has complete control of i/o.

    Thanks,
    Hirokazu Takahashi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2008-08-07 10:33    [W:0.025 / U:0.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site