Re: objrmap and vmtruncate

William Lee Irwin III (wli@holomorphy.com)
Sun, 6 Apr 2003 01:41:28 -0800


On Sat, Apr 05, 2003 at 03:25:24PM -0800, William Lee Irwin III wrote:
>> I apparently erred when I claimed this kind of test would not provide
>> useful figures of merit for page replacement algorithms. There appears
>> to be more to life than picking the right pages.

On Sun, Apr 06, 2003 at 05:26:03AM -0400, Benjamin LaHaise wrote:
> This is precisely the conclusion which davem and myself came to, and
> explained at the beginning of this whole ordeal. It all boils down to
> the complexity of the algorithm, and the fact that the number of cache
> misses scales with that.
> Can we get on with merging pgcl to mitigate some of the rmap costs now? ;-)

No!

You do _not_ want me to merge it now unless you're speaking of drivers/
and arch code from the standpoint of "advance notice", "version skew",
or "compatibility API's". I am not done and the core impacts of the
current source are unacceptable (even to me, who wrote the 2.5 stuff)
and furthermore the antifragmentation bits are so grossly incomplete
it's not worthy of being called a full implementation. I am willing to
accept "help" but would prefer it not be given; yes I am being slow,
but unless it's a true emergency I would much prefer to do my own
homework as it were, if only for my own edification.

This _may_ sound like it's "anti-open", but it isn't really. The fact
is this is important, so even intermediate steps need discussion, but
at the same time, I am working hard, learning, and absolutely must not
be "bailed out" except if this becomes truly critical, for otherwise I
won't learn enough to maintain it myself and as I've taken on this
myself, I need to be able to take up the burden of maintaining it even
after it's merged -- that is, by learning the hard way, not bailouts.

Even beyond this general statement, the supposed pte_chain space
reductions owing to page clustering are an open question with respect
to effectiveness. I myself would need better a priori evidence and/or
empirical evidence of this to add it to my list of claimed benefits.

All this said, the drivers and the arch code bits are actually largely
trivial substitions. If the discussion is truly limited to that, I'm
okay with sending in pieces; still it makes me uneasy to do anything
while the code I have now is so far from working as it truly should.

-- wli
-
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/