Right, and as we just discussed on irc, it's a useful effect - only if we
control it, so that stopped or slowed processes do eventually get forcibly
elevated in terms of IO priority so they can make progress, after being sat
upon by more agressive/successful processes long enough. And we can control
this, it's just going to take a few months to get basic issues of IO queues,
RSS accounting, etc. out of the way so we can address it.
The trouble I have with paying a lot of attention to dbench results at this
point is - we're measuring effects of kernel behaviour that is, at this
point, uncontrolled and effectively random. IOW, we're not measuring the
effects that we're interested in just now. If we need to know IO throughput,
we need to use benches that test exactly that, and not other randomly
interacting effects. As they said on Laugh-in many moons ago: 'very
interesting, but useless'.
-- Daniel - 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/