[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.024 / U:0.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site