lkml.org 
[lkml]   [2007]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/9]: Reduce Log I/O latency
    On Fri, Nov 23, 2007 at 09:29:09AM +1100, David Chinner wrote:
    > On Thu, Nov 22, 2007 at 12:10:29PM -0600, Matt Mackall wrote:
    > > On Thu, Nov 22, 2007 at 09:31:59PM +1100, David Chinner wrote:
    > > [...]
    > > > > In other words, I/O priority is per-spindle and not per-filesystem and
    > > > > thus this change has consequences that leak outside the filesystem in
    > > > > question. That's bad.
    > > >
    > > > This has nothing to do with this patch - it's a problem with sharing
    > > > a single resource in a RT system between two non-deterministic
    > > > constructs. e.g. I can put two ext3 filesystems on the one spindle,
    > > > run two completely independent RT workloads on the different
    > > > filesystems and have one workload DOS the other due to differences
    > > > in priority at the spindle.
    > >
    > > Sure. And it's up to the RT system designer not to do something stupid
    > > like that. The problem is that your patch potentially promotes a
    > > non-RT I/O activity to an RT one without regard to the rest of the
    > > system.
    >
    > So this:
    >
    > http://marc.info/?l=linux-kernel&m=119247074517414&w=2
    >
    > shouldn't be allowed, either? (rt kjournald for ext3)

    No, I think not. If a user wants to manually promote kjournald, that's fine.

    > > Perfectly understood. And that's fine. A system designer is allowed to
    > > shoot himself in the foot.
    >
    > Ok. I'll point anyone that complains at you, Matt ;)
    >
    > > I don't think there's any fundamental reason the I/O subsystem or
    > > filesystems can't be taught to handle priority inversion, which is
    > > much more acceptable and general fix.
    >
    > See my reply to Andi.

    I did. And I'll admit it's pretty thorny and I certainly don't know
    enough about XFS internals to comment further.

    > > If I've got XFS on filesystems A and B on the same spindle (or volume
    > > group?) and my real RT I/O takes place only on B, then I want log
    > > flushing to happen in RT on B. But -never on A-. If I can do this with
    > > a tunable, I'm perfectly happy.
    >
    > No, not another mount option. I'm just going to drop this one for
    > now...

    I was actually just suggesting allowing a user to do ioprio_set on the
    appropriate kernel threads.

    --
    Mathematics is the supreme nostalgia of our time.
    -
    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: 2007-11-23 01:23    [W:0.027 / U:125.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site