Messages in this thread | | | Date | Sun, 6 Apr 2003 01:41:28 -0800 | From | William Lee Irwin III <> | Subject | Re: objrmap and vmtruncate |
| |
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/
| |