On 18.03.2007 [00:08:38 +1100], David Gibson wrote:
> 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.
Hrm, I'm not sure I like that -- It would mean that you can't actually
use the result of the call, in all cases. That is, we'd have to compare
the result to the parameter every time.
> 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.
When would we do this? I don't see any case that we would in the lib or
in the tests, right now, but I'm not looking too hard (have a final in
the morning).
But, IA64 only has one slice, as far as I can see, yes? I'm not sure how
best to handle IA64 in this regard.
> 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
Right, and that's precisely how I use it in the partial segment
remapping code (added local helpers for get_next_slice_start() and
get_previous_slice_end(), which could probably go into hugeutils.c as
well).
Then again, we're not supporting IA64 there anyways :)
> 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.
See the partial remap code for the only real user of the function (other
than morecore and brk_near_huge).
I think the most useful semantics are:
for hugetlbfs_slice_end/hugetlbfs_slice_start, only respond about huge
pages. Perhaps rename them to hugepage_slice_start/end, to indicate they
aren't really about the fs, per se, but about the VM/hardware.
For an address which could potentially a process could map hugepages at,
hugetlbfs_slice_start/end(addr) gives the appropriate endpoint
(inclusive) of the enclosing slice.
If the address, however, is not valid for hugepage mappings, I'm not
sure what the best method is. I say we flag an error somehow (not sure
how, admittedly...). Maybe your semantics are best. If the address is
not valid, and they ask for the start, return addr + 1 and if they ask
for the end, give addr - 1. This says nothing about whether or not the
mapping will actually succeed or not (on power, where smallpages may
already be there, or on x86_64, where something might already be mapped
there period), but that makes sense to me. This is basically a simple VM
query interface.
Then we add functions
next_hugetlb_slice_start
previous_hugetlb_slice_end
which will be used in morecore and partial_remap. They will actually
handle the case where the address may not be suitable for huge pages
(perhaps an error was flagged), but we want to still use them so give us
the closest valid place (or tell us where the previous one ended). I've
basically got these in the partial_remap code.
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
