On Wed, Jul 31, 2013 at 02:37:53PM +0900, Joonsoo Kim wrote:

Hello, David.

On Mon, Jul 29, 2013 at 05:28:23PM +1000, David Gibson wrote:

quoted

On Mon, Jul 29, 2013 at 02:32:08PM +0900, Joonsoo Kim wrote:

quoted

If parallel fault occur, we can fail to allocate a hugepage,
because many threads dequeue a hugepage to handle a fault of same address.
This makes reserved pool shortage just for a little while and this cause
faulting thread who is ensured to have enough reserved hugepages
to get a SIGBUS signal.

It's not just about reserved pages.  The same race can happen
perfectly well when you're really, truly allocating the last hugepage
in the system.

Yes, you are right.
This is a critical comment to this patchset :(

IIUC, the case you mentioned is about tasks which have a mapping
with MAP_NORESERVE.

Any mapping that doesn't use the reserved pool, not just
MAP_NORESERVE.  For example, if a process makes a MAP_PRIVATE mapping,
then fork()s then the mapping is instantiated in the child, that will
not draw from the reserved pool.

Should we ensure them to allocate the last hugepage?
They map a region with MAP_NORESERVE, so don't assume that their requests
always succeed.

If the pages are available, people get cranky if it fails for no
apparent reason, MAP_NORESERVE or not.  They get especially cranky if
it sometimes fails and sometimes doesn't due to a race condition.

-- 
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