Re: Bug with shared memory.

[Martin J. Bligh]

> 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.

M.