Re: Bug with shared memory.
Martin J. Bligh (Martin.Bligh@us.ibm.com)
Mon, 20 May 2002 09:13:53 -0700
> About rmap design I would very much appreciate if Rik could make a
> version of his patch that implements rmap on top of current -aa (it
> wouldn't be a rewrite, just a porting of the strict rmap feature),
> so we can compare apples to apples and benchmark the effect of the
> rmap patch, not the rmap + the hybrid, most of the slowdown during
> paging is most probably due the hybrid, not because of the rmap design,
> the rmap design if something should make things a bit faster during
> swapout infact, by being a bit slower in the more important fast paths.
> It is definitely possible to put a strict rmap on top of -aa without
> the huge "hybrid" thing attached to the rmap code, so without impacting
> at all the rest of the vm. It's just a matter of adding the try_to_unmap
> in shrink_cache and deleting the swap_out call (it's almost as easy as
> shipping a version of Windows without a web browser installed by default).
Is it really the rmap patch, or is this Alan's VM as a whole?
Could you take a look at http://www.surriel.com/patches/ and
see if the rmap 13 patch there is still objectionable to you?
I've been benchmarking rmap 13 against mainline (2.4.19-pre7)
and with the latest lock breakup changes performance now seems
to be about equivalent to mainline (for kernel compile on NUMA-Q).
Those changes reduced system time from 650s to 160s. The only
reason I haven't published results "officially" yet is that I
was sorting out some timer problems with the machine.
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/