>> >> But there seems an obvious solution here: given your value in those >> >> bits (call it 'n'), the why not apply a multiplier. I mean, certainly >> >> you never want a value <= 12 for n, and I suspect that the reasonable >> >> minimum could be much larger (e.g., 2^16). Call that minimum M. Then >> >> you could interpret the value in your bits as meaning a page size of >> >> >> >> (2^n) * M >> > >> > I considered that, but it would seem ugly and does not add that >> > many bits. >> > >> >> >> >> > So this will use up all remaining flag bits now. >> >> >> >> On the other hand, that seems really bad. It looks like that kills the >> >> ability to further extend the mmap() API with new flags in the future. >> >> It doesn't sound like we should be doing that. >> > >> > You can always add flags to PROT or add a mmap3(). Has been done before. >> > Or just don't do any new MAP_SECURITY_HOLEs >> >> There seems to be a reasonable argument here for an mmap3() with a >> 64-bit flags argument... > > It's just a pain to deploy. > > I think I would rather do the offset then. That could still handle > PowerPC > > 14 + 31 = 44 = 16GB (minimum size 16K)
Since PowerPC already allows 16GB page sizes, doesn't there need to be allowance for the possibility of future expansion? Choosing a larger minimum size (like 2^16) would allow that. Does the minimum size need to be 16k? (Surely, if you want a HUGEPAGE, you want a bigger page than that? I am not sure.) -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
