[lkml]   [2002]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bug with shared memory.
> 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 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.123 / U:20.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site