On 02.03.2007 [15:46:07 -0800], Nishanth Aravamudan wrote: > On 02.03.2007 [18:24:26 +1100], David Gibson wrote: > > On Wed, Feb 28, 2007 at 08:22:36AM -0800, Nishanth Aravamudan wrote: > > > On 27.02.2007 [10:47:31 +1100], David Gibson wrote: > > > > On Mon, Feb 26, 2007 at 03:21:26PM -0800, Nishanth Aravamudan wrote: > > > > > Author: Nishanth Aravamudan <[EMAIL PROTECTED]> > > > > > Date: Mon Feb 26 15:17:54 2007 -0800 > > > > > > > > > > hugeutils: add address parameter to hugetlbfs_vaddr_granularity > > > > > > > > > > On ppc64, the actual granularity of hugepage requests depends on the > > > > > address in question. Specify the three cases (0-4G, 4G-1TB, 1TB+) in > > > > > the > > > > > function. This is useful for the partial_remap code, as it would > > > > > (effectively) never run on ppc64 otherwise (would need a 1TB or larger > > > > > segment, without relinking). > > > > > > > > I've thought about doing something like this before. However, the > > > > semantics as they stand are a little bit fuzzy. What I'd prefer, if > > > > you want to get finer-grained information about the page-size regions > > > > is a pair of functions to find the end and beginning of a page-size > > > > slice, given an address. So: > > > > > > > > void *hugetlbfs_slice_end(void *addr); > > > > void *hugetlbfs_slice_start(void *addr); > > > > > > > > The "slice" terminology is something BenH has started using for these > > > > address space regionsin some recent kernel patches. > > > > > > I'm willing to believe I'm doing something incredibly stupid, but here's > > > my patch. I had to use a bunch of macros, as I was getting a headache > > > from all the casts and the constants. How do I make this cleaner? Or do > > > I give up on this? > > > > Well, for starters, you want to get rid of > > hugetlbfs_vaddr_granularity() entirely. > > <snip> > > > Except.. I think hugetlbfs_slice_end() will actually need to return > > the end of the slice, not the beginning of the next one as it does > > now. I don't like that semantic on the whole, but without it, for > > 32-bit programs hugetlbfs_slice_end() will return 0 for sufficiently > > high addresses. I'd prefer to reserve the case where > > hugetlbfs_slice_end(adde) < addr to mean that the given address is > > already outside the potentially valid range for hugepage addresses (so > > if we ever support ia64, slice_start() and slice_end() end would > > return the constant addresses marking the ends of their fixed hugepage > > region). > > Thanks for the review David. I'm not entirely sure about the semantics > still. I got what you were saying, but wasn't sure of the best way to > implement it.
Independent of this patch, I'm starting to feel like we could maybe do a better job of abstracting out the arch-specific bits of the library (including some tests which only really have meaning (or even run!) on power, for instance). Would people be opposed to perhaps a little bit of a reorg, where we have arch-specific hooks for some things, which maybe default defined to no-ops. And then a bit of a reoorg of run_tests.sh to have a base set of tests run on all archs, and then add to those, the arch-specific tests? Thanks, Nish -- Nishanth Aravamudan <[EMAIL PROTECTED]> IBM Linux Technology Center ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
