Re: [PATCH] anobjrmap 1/6 objrmap

["Martin J. Bligh" <mbligh@aracnet.com>]

> here it's not the fastest (though a 0.03 difference should be in the
> error range with an unlimited -j)
>
> overall I think for the fast path we can conclude they're at least
> equally fast.

Yup, I think they're all within the noise level between anon_mm and anon_vma,
though both are faster than partial by something at lease statistically
significant (though maybe not even enough to care about for these 
workloads).

> it's interesting I get 0 standard deviation. Is it possible I get lower
> standard deviation because you run it less times? just wondering. I'd
> expect SDET has a default number of passes, so I expect the answer is no
> of course.

Yeah, it does 5 passes, and throws away the fastest and slowest. So it's
only 3 it's calculating off ... I think you just got lucky with a 0.0% ;-)
That's the most stable way I found of getting consistent results.

> it's one of the -mm patches probably that boosts those bits (the
> cost page_add_rmap and the page faults should be the same with both
> anon-vma and anonmm). as for the regression, the pgd_alloc slowdown is
> the unslabify one from andrew that releases 8 bytes per page in 32bit
> archs and 16 bytes per page in 64bit archs.

OK, great ... thanks for the info. I think I'd happily pay that cost in
pgd_alloc for the space gain - kernbench & SDET are about as bad as it
gets on pgd_alloc, so that seems like a good tradeoff.
 
> My current page_t is now 36 bytes (compared to 48bytes of 2.4) in 32bit
> archs, and 56bytes on 64bit archs (hope I counted right this time, Hugh
> says I'm counting wrong the page_t, methinks we were looking different
> source trees instead but maybe I was really counting wrong ;).

IIRC, with PAE etc on, mainline is 44 bytes. So if we saved 8 from Andrew's
change, and 4 from objrmap, I'd be hoping for 32?

M.