On Sun, Mar 27, 2011 at 10:25:23PM +0800, rocky wrote:
> Hey :)
>
> I am using libhugetlbfs to test ARM hugetlb support , I am a bit of
> confused of some test cases in libhugetlbfs.
> take alloc-instantiate-race for exmapple,
> for shared mapping, why does we employ fork to produce 2 process do the
> racing?
> while for private mapping, we actually use pthread do it .
> I don't get it the reason of this testing theme,
alloc-instantiate-race is designed to test for a specific kernel bug
we had at one point. This bug occurred when two processes or threads
raced to instantiate the last available huge page in the system. The
buggy case only occurred when the two threads/processes were
attempting to instantiate the *same* huge page - that is, that if the
two faults did not race, but occurred sequentially the second fault
would simply use the hugepage already instantiated by the first
fault. The bug was that the second fault when racing would fail to
allocate a new page (because none were available) and fail the fault,
even though if it waited the necessary page would be supplied by the
first fault.
There are two situations where this can occur. The first is in a
MAP_SHARED mapping, shared between two processes. Here the race it to
instantiate the same page in the shared mapping's radix tree. We
could theoretically test this with threads instead of processes, but
in that case we wouldn't really be testing the proper synchronization
between different processes that share a mapping.
The second case is a MAP_PRIVATE mapping, with the race being between
two threads sharing that private mapping (since a private mapping is
not shared between processes). In this case the race is to
instantiate the same page in the mm's page tables which are shared
between the threads.
--
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
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
