On Tue, Feb 12, 2008 at 04:30:51PM -0800, Nishanth Aravamudan wrote:
>
> tests: CONFIG out if required number of free hugepages are unavailable
>
> Some tests (not all) require a certain number of hugepages (known in
> advance) to work. Right now, we will fail to mmap() with ENOMEM, when
> it's really a configuration issue (I'd argue). Use what was previously a
> local helper, hugetlbfs_num_free_pages(), but renamed to
> num_free_hpages() [as, as far as I can tell, it is not technically tied
> to hugetlbfs], to see how many hugepages are free before we run the
> affected tests.
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> ---
> I can split this into separate bits (the rename / globalization could be
> two separate patches, then the users could be added), but I wanted to
> get this out as an RFC. There are two follow-on test fixes that I'm
> working on still: overflowing long when calculating number of hugepages
> requested * hpage_size (which includes overflowing long in the
> calculation of hpage_size!) and [perhaps] dealing better with mmap()
> failing due to lack of space in the address space.
Certainly we should do CONFIG() for these cases, not FAIL(). However,
I'm uneasy about exporting num_free_hugepages().
I've deliberately avoided exporting that interface so far, because
most obvious uses of it are racy (because someone else could grab a
bunch of pages between checking the total and performing our map for
real). Now in the case of the testsuite, where it's purely a helpful
diagnostic, it doesn't really matter, but I don't want people to look
at this usage and think that's an acceptable way of checking if there
are enough hugepages for their app.
What we should perhaps do instead, is explicitly check for ENOMEM on
the first map, and CONFIG() instead of FAIL() on that case.
--
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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
