On Fri, Mar 16, 2007 at 10:14:23AM -0700, Nishanth Aravamudan wrote:
> On 16.03.2007 [10:12:33 -0700], Nishanth Aravamudan wrote:
> > On 16.03.2007 [10:43:42 +1100], David Gibson wrote:
> > > On Thu, Mar 15, 2007 at 12:28:25PM -0700, Nishanth Aravamudan wrote:
> > > > truncate_above_4GB: Must be built like it is on powerpc due to address
> > > > space restrictions on hugepages.
> > > > brk_near_huge: add next_chunk case for ia64 to express that IA64 huge
> > > > page mappings start at 0x8000000000000000UL (2^63).
> > > > icache-hygeine: IA64 also gets a SIGILL in the icache-hygeiene test, so
> > > > add it to the powerpc conditional and update the comment.
> > > >
> > > > Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> > >
> > > Acked-by: David Gibson <[EMAIL PROTECTED]>
> > >
> > > [snip]
> > > > diff --git a/tests/brk_near_huge.c b/tests/brk_near_huge.c
> > > > index be54914..4ed6bc9 100644
> > > > --- a/tests/brk_near_huge.c
> > > > +++ b/tests/brk_near_huge.c
> > > > @@ -47,11 +47,16 @@ void *next_chunk(void *addr)
> > > > /* 1TB segments above */
> > > > return PALIGN(addr, 0x10000000000UL);
> > > > }
> > > > -#elif __powerpc__
> > > > +#elif defined(__powerpc__)
> > > > void *next_chunk(void *addr)
> > > > {
> > > > return PALIGN(addr, 0x10000000UL);
> > > > }
> > > > +#elif defined(__ia64__)
> > > > +void *next_chunk(void *addr)
> > > > +{
> > > > + return PALIGN(addr, 0x8000000000000000UL);
> > > > +}
> > >
> > > Now that we have the slice functions in the library, we should export
> > > them and use them here.
> >
> > Good idea, I'll spin up a patch to do this. Hrm, need to add a case to
> > the slice functions for ia64 after all.
> >
> > As I understand it, IA64 has one large slice that can contain huge pages
> > from 2^63 to the end of the address space? Is that accurate?
> >
> > So start will always be 2^63 and end will always be 2^64-1?
>
> Presuming the address passed in is actually between the two -- so does
> that mean we should return NULL for other addresses? Since hugepages
> can't be used there (with short VHPT mode).
Um, I'm not 100% sure on this. I was thinking of reserving the
(otherwise peculiar) results slice_end(addr) < (addr) and
slice_begin(addr) > addr to mean that the addr lies outside a fixed
region suitable for hugepages, precisely to deal with the ia64 case.
However that's not going to work if we attempt to use the slice
functions to find an area suitable for normal pages, having made a
hugepage mapping.
Ugh, and there's another kinda problem here; the ia64 user address
space is non-contiguous. Which means that for at least one sensible
definition of the terms,
(beginning of next slice) != (end of this slice) + 1
Erm.. I think we want to look at the actual use cases of the slice
functions to work out the most sensible set of semantics here. It's
conceivable we'll even have to extend the API - e.g. separate
slice_end(), next_slice() functions, or requiring a parameter
requesting the type of page desired.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
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
