Re: [PATCH] mm: use PageAnon() and PageKsm() helpers in page_anon_vma()

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

 



On Thu, 2 Apr 2015 01:02:46 +0300 "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> wrote:

> On Wed, Apr 01, 2015 at 12:57:45PM -0700, Andrew Morton wrote:
> > On Wed, 1 Apr 2015 14:50:54 +0300 "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> wrote:
> > 
> > > >From adc384977898173d65c2567fc5eb421da9b272e0 Mon Sep 17 00:00:00 2001
> > > From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
> > > Date: Wed, 1 Apr 2015 14:33:56 +0300
> > > Subject: [PATCH] mm: uninline and cleanup page-mapping related helpers
> > > 
> > > Most-used page->mapping helper -- page_mapping() -- has already
> > > uninlined. Let's uninline also page_rmapping() and page_anon_vma().
> > > It saves us depending on configuration around 400 bytes in text:
> > > 
> > >    text	   data	    bss	    dec	    hex	filename
> > >  660318	  99254	 410000	1169572	 11d8a4	mm/built-in.o-before
> > >  659854	  99254	 410000	1169108	 11d6d4	mm/built-in.o
> > 
> > Well, code size isn't the only thing to care about.  Some functions
> > really should be inlined for performance reasons even if that makes the
> > overall code larger.  But the changes you're proposing here look OK to
> > me.
> > 
> > > As side effect page_anon_vma() now works properly on tail pages.
> > 
> > Let's fix the bug in a separate patch, please.  One which can be
> > backported to earlier kernels if that should be needed.  ie: it should
> > precede any uninlining.
> 
> The bug is not triggerable in current upsteam. AFAIK, we don't call
> page_anon_vma() on tail pages of THP, since we don't map THP with PTEs
> yet. For rest of cases we will get NULL, which is valid answer.

argh.  It rather helps if you can tell me when this happens (and which
patch it fixes).  I sometimes spend quite a bit of time runnnig around
in circles wondering what the heck tree/patch just got fixed.

> Do you still want "page = compound_head(page);" line in separate patch?

I think that would be best.  That way the offending patch gets fixed
and doesn't get bundled up with an unrelated change.

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