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

    > > - Implement a block layer resource controller. dm-ioband is a working
    > > solution and feature rich but its dependency on the dm infrastructure is
    > > likely to find opposition (the dm layer does not handle barriers
    > > properly and the maximum size of I/O requests can be limited in some
    > > cases). In such a case, we could either try to build a standalone
    > > resource controller based on dm-ioband (which would probably hook into
    > > generic_make_request) or try to come up with something new.
    >
    > I doubt about the maximum size of I/O requests problem. You can't avoid
    > this problem as far as you use device mapper modules with such a bad
    > manner, even if the controller is implemented as a stand-alone controller.
    > There is no limitation if you only use dm-ioband without any other device
    > mapper modules.

    Ryo told me this isn't true anymore. The dm infrastructure introduced
    a new feature to support multiple page-sized I/O requests, that was
    just merged to the current linux tree. So you and me don't need to
    worry about this stuff anymore.

    Ryo said he was going to make dm-ioband support this new feature and
    post the patches soon.

    > And I think the device mapper team just started designing barriers support.
    > I guess it won't take long. Right, Alasdair?
    > We should know it is logically impossible to support barriers on some
    > types of device mapper modules such as LVM. You can't avoid the barrier
    > problem when you use this kind of multiple devices even if you implement
    > the controller in the block layer.
    >
    > But I think a stand-alone implementation will have a merit that it
    > makes it easier to setup the configuration rather than dm-ioband.
    > From this point of view, it would be good that you move the algorithm
    > of dm-ioband into the block layer.
    > On the other hand, we should know it will make it impossible to use
    > the dm infrastructure from the controller, though it isn't so rich.
    >
    > > - If the I/O tracking patches make it into the kernel we could move on
    > > and try to get the Cgroup extensions to CFQ and AS mentioned before (see
    > > (1), (2), and (3) above for details) merged.
    > > - Delegate the task of controlling the rate at which a task can
    > > generate dirty pages to the memory controller.
    > >
    > > This RFC is somewhat vague but my feeling is that we build some
    > > consensus on the goals and basic design aspects before delving into
    > > implementation details.
    > >
    > > I would appreciate your comments and feedback.
    > >
    > > - Fernando

    Thanks,
    Hirokazu Takahashi.


    \
     
     \ /
      Last update: 2008-08-08 16:35    [W:4.082 / U:0.388 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site