On Fri, Aug 29, 2008 at 09:19:41AM -0500, Adam Litke wrote:
> On Fri, 2008-08-29 at 12:25 +1000, David Gibson wrote:
> > On Thu, Aug 28, 2008 at 08:51:58AM -0500, Adam Litke wrote:
> > > On Thu, 2008-08-28 at 11:44 +1000, David Gibson wrote:
> > > > On Wed, Aug 27, 2008 at 06:34:54PM +0000, Adam Litke wrote:
> > > > > It is now possible for 32 and 64 bit applications to require
> > > > > different mount
> > > > > points. For example: powerpc 16G pages can only be used by 64 bit
> > > > > apps. To
> > > > > handle this case, check for mount points in both a 32 and 64 bit
> > > > > context. Only
> > > > > run tests for a word size with a valid mount point.
> > > > >
> > > > > When cleaning up elflink share files, remove files from all detected
> > > > > mount
> > > > > points.
> > > >
> > > > I think you're thinking about this the wrong way around. To test
> > > > thoroughly, we want to test as many page sizes as are available. So
> > > > rather than attempting to find a single pagesize/mountpoint for each
> > > > wordsize, we should instead attempt to run through the whole testsuite
> > > > for each pagesize. Then it's just a matter of not running the 32-bit
> > > > tests when we're doing a run on pagesize that's too big.
> > >
> > > While I agree with you that we should end up testing all of the
> > > available page sizes (and possibly even mixing them within tests) I
> > > think that is a separate patch series. This patch is specifically (and
> > > simply) about recognizing that the list of valid mount points may differ
> > > between 32 and 64 bit applications.
> >
> > Hrm. I guess.
> >
> > > It would be relatively easy to test different page sizes through the use
> > > of the HUGETLB_PATH environment variable in run_tests.sh to manipulate
> > > the available hugetlbfs mount points available to test cases. This is
> > > how I have been testing things on my own box. Producing a patch for
> > > this is near the top of my list.
> >
> > Wouldn't it be simpler for the hugeutls code simply to reject any
> > mounts (either from HUGETLB_PATH or the mounts file) that have a
> > pagesize we can't use? Then we don't need to fiddle with which is
> > which from the run_tests.sh script. Well, except for quota, which is
> > weird because it makes its own mount.
>
> The code already does this. See hugetlbfs_test_pagesize(). The
> overflow checking in that function should eliminate the mount from
> consideration if its size cannot be properly represented in a native
> LONG.
>
> The purpose of the run_tests.sh logic is to simply not run tests for a
> word size that will not have a valid mount point to use (because, for
> example, the only mounted size was eliminated by the check I describe
> above).
Ah, yeah. Fair enough.
--
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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
