Re: shared pagetable benchmarking

To what extent is that a "real" workload?

It was meant to be a simulation of a real customer enviroment,
I don't think it's unrealistic (they were actually trying to push it
to at least twice that).

What other applications are affected, and to what extent?

Anything that does heavy sharing. Databases and Java heaps spring
to mind.

Why are hugepages not a sufficient solution?

They may be for some workloads, but it's not as generalised. For
instance, one other thing that's being muttered about a lot is very
large heaps for Java workloads, and they want those swap backed.
Large pages also requires application modification and machine setup
for static pool size reservations in the current implementation.

Is this problem sufficiently common to warrant the inclusion of
pagetable sharing in the main kernel, as opposed to a specialised
Oracle/DB2 derivative?

If we can get it not to degrade anything else (eg fork on small tasks),
I think it's worthwhile. I *think* we're there now, though a few more
perf checks are probably needed.

quoted

I think the long-term fix for the rmap performance hit is object-based
RMAP (doing the reverse mappings shared on a per-area basis) which we've
talked about, but not for 2.6 ... it may not turn out to be that hard
though ... K42 did it before.

I think we can do a few things still in the 2.6 context.  The fact that
my "apply seventy patches with patch-scripts" test takes 350,000
pagefaults in 13 seconds makes one go "hmm".

Fixing that would be a worthy goal, IMHO.

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/