Re: [RFC/PATCH] prepare_unmapped_area

[Adam Litke <agl@us.ibm.com>]

On Wed, 2007-02-07 at 07:12 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2007-02-06 at 09:56 -0600, Adam Litke wrote:
> > On Tue, 2007-02-06 at 16:04 +1100, Benjamin Herrenschmidt wrote:
> > > Hi folks !
> > > 
> > > On Cell, I have, for performance reasons, a need to create special
> > > mappings of SPEs that use a different page size as the system base page
> > > size _and_ as the huge page size.
> > > 
> > > Due to the way the PowerPC memory management works, however, I can only
> > > have one page size per "segment" of 256MB (or 1T) and thus after such a
> > > mapping have been created in its own segment, I need to constraint
> > > -other- vma's to stay out of that area.
> > > 
> > > This currently cannot be done with the existing arch hooks (because of
> > > MAP_FIXED). However, the hugetlbfs code already has a hack in there to
> > > do the exact same thing for huge pages. Thus, this patch moves that hack
> > > into something that can be overriden by the architectures. This approach
> > > was choosen as the less ugly of the uglies after discussing with Nick
> > > Piggin. If somebody has a better idea, I'd love to hear it.
> > 
> > Hi Ben.  Would my patch from last Jan 31 entitled "[PATCH 5/6] Abstract
> > is_hugepage_only_range" (attached for your convienence) solve this
> > problem?
> 
> I don't see how your patch abstracts is_hugepage_only_range tho... you
> still call it at the same spot, you abstracted prepare_hugepage_range.

Yeah, you're right... Former revisions of the patch created a function
called is_special_range() which for the moment only called
is_hugepage_only_range().  The thought was that other types of "special
ranges" could be checked for in this function.  I guess that's basically
the same idea as validate_area() below.  That would work for me.

> I was talking to hch and arjan yesterday on irc and we though about
> having an mm hook validate_area() that could replace the
> is_hugepage_only_range() hack and deal with my issue as well. As for
> having prepare in the fops, do we need it at all if we call fops->g_u_a
> in the MAP_FIXED case ?

Nah, if we cleaned up g_u_a() so that it is always called, away goes the
need for f_ops->prepare_unmapped_area().

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center

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