On 23 September 2015 at 13:00, Richard Henderson <r...@twiddle.net> wrote: > On 09/23/2015 12:39 PM, Peter Maydell wrote: >> I think we're now doing the MADV_HUGEPAGE over "buffer size >> minus a page" rather than "buffer size". Does that mean >> we've gone from doing the madvise on a whole number of >> hugepages to doing it on something that's not a whole number >> of hugepages, and if so does the kernel decide not to use >> hugepages here? > > On the whole I don't think it matters. The static buffer isn't page aligned > to > begin with, much less hugepage aligned, so the fact that we're allocating a > round number like 32mb here doesn't really mean much. The beginning and/or > end > pages of the buffer definitely aren't going to be hugepage. > > Worse, the same is true for the mmap path, since I've never seen the kernel > select a hugepage aligned address. You'd think that adding MAP_HUGEPAGE would > be akin to MADV_HUGEPAGE, with the additional hint that the address should be > appropriately aligned for the hugepage, but no. It implies forced use of > something from the hugepage pool and that requires extra suid capabilities. > > I've wondered about over-allocating on the mmap path, so that we can choose > the > hugepage aligned subregion. But as far as I can tell, my kernel doesn't > allocate hugepages at all, no matter what we do. So it seems a little silly > to > go so far out of the way to get an aligned buffer.
This raises the converse question of "why are we bothering with MADV_HUGEPAGE at all?" :-) -- PMM
