Re: [PATCH 17/18] mm, hugetlb: retry if we fail to allocate a hugepage with use_reserve

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2013-08-05 at 16:36 +0900, Joonsoo Kim wrote:
> > 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.
> 
> Hello,
> 
> Hmm... Okay. I will try to implement another way to protect race condition.
> Maybe it is the best to use a table mutex :)
> Anyway, please give me a time, guys.

So another option is to take the mutex table patchset for now as it
*does* improve things a great deal, then, when ready, get rid of the
instantiation lock all together.

Thanks,
Davidlohr

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]