Messages in this thread | | | Date | Wed, 24 Mar 2004 08:35:46 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH] anobjrmap 1/6 objrmap |
| |
> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |