On Sat, Jan 12, 2013 at 07:43:08PM -0600, Simon Jeons wrote: > On Sat, 2013-01-12 at 05:36 +0200, Kirill A. Shutemov wrote: > > On Fri, Jan 11, 2013 at 03:53:34PM -0800, Michel Lespinasse wrote: > > > Hi, > > > > > > follow_page() has code to return ERR_PTR(-EFAULT) when it encounters > > > the zero page and FOLL_DUMP flag is passed - this is used to avoid > > > dumping the zero page to disk when doing core dumps, and also by > > > munlock to avoid having potentially large number of threads trying to > > > munlock the zero page at once, which we can't reclaim anyway. > > > > > > We don't have the corresponding logic when follow_page() encounters a > > > huge zero page. I think we should, preferably before 3.8. However, I > > > am slightly confused as to what to do for the munlock case, as the > > > huge zero page actually does seem to be reclaimable. My guess is that > > > we could still skip the munlocks, until the zero page is actually > > > reclaimed at which point we should check if we can munlock it. > > > > > > Kirill, is this something you would have time to look into ? > > > > Nice catch! Thank you. > > > > I don't think we should do anything about mlock(). Huge zero page cannot > > be mlocked -- it will not pass page->mapping check in > > Hi Kirill, > > What's store in page->mapping of huge zero page? NULL. -- Kirill A. Shutemov
Attachment:
signature.asc
Description: Digital signature