I could try "fast is beautiful" or "beauty is in the eye of the beholder",
but I think I'll stick with "beauty isn't the point just now".
> Don't bother doing teardown yet. I have patches which batch
> all the zap_page_range activity into 16-page chunks, so we
> eventually end up in a single function with 16 virtually-contiguous
> pages to release. Adding the batched locking to that will
> be simple.
Great. Well, both the locking locality of anonymous pages and the dispersion
of mmaped pages could be improved considrably, so maybe I'll play around with
those a little. Taking a wild guess, it might be good for another 5-10%
overhead reduction, and won't impact the basic structure.
> Sigh. I have a test which sends the 2.5.30 VM into a five-minute
That doesn't sound like a rmap problem per se. Is the test posted?
> and which immediately panics latest -ac with pte_chain oom.
> Remind me again why all this is worth it?
It will be worth it when we finally have a system that swaps well and doesn't
die if you throw a lot of disk IO at it (like BSD). It will be doubly worth
it when active defragmentation happens.
What we will end up with at the end of this cycle will have all the solidity
and flexibility of the BSD VM with little of the complexity. According to me
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/