Re: huge zero page vs FOLL_DUMP

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

 



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


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