linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org
Subject: Re: [RFC 00/11] Remove 'order' argument from many mm functions
Date: Wed, 8 May 2019 18:58:09 -0700	[thread overview]
Message-ID: <20190509015809.GB26131@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20190507040609.21746-1-willy@infradead.org>

On Mon, May 06, 2019 at 09:05:58PM -0700, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> 
> It's possible to save a few hundred bytes from the kernel text by moving
> the 'order' argument into the GFP flags.  I had the idea while I was
> playing with THP pagecache (notably, I didn't want to add an 'order'
> parameter to pagecache_get_page())
> 
> What I got for a -tiny config for page_alloc.o (with a tinyconfig,
> x86-32) after each step:
> 
>    text	   data	    bss	    dec	    hex	filename
>   21462	    349	     44	  21855	   555f	1.o
>   21447	    349	     44	  21840	   5550	2.o
>   21415	    349	     44	  21808	   5530	3.o
>   21399	    349	     44	  21792	   5520	4.o
>   21399	    349	     44	  21792	   5520	5.o
>   21367	    349	     44	  21760	   5500	6.o
>   21303	    349	     44	  21696	   54c0	7.o
>   21303	    349	     44	  21696	   54c0	8.o
>   21303	    349	     44	  21696	   54c0	9.o
>   21303	    349	     44	  21696	   54c0	A.o
>   21303	    349	     44	  21696	   54c0	B.o
> 
> I assure you that the callers all shrink as well.  vmscan.o also
> shrinks, but I didn't keep detailed records.
> 
> Anyway, this is just a quick POC due to me being on an aeroplane for
> most of today.  Maybe we don't want to spend five GFP bits on this.
> Some bits of this could be pulled out and applied even if we don't want
> to go for the main objective.  eg rmqueue_pcplist() doesn't use its
> gfp_flags argument.

Over all I may just be a simpleton WRT this but I'm not sure that the added
complexity justifies the gain.

But other than the 1 patch I don't see anything technically wrong.  So I
guess...

Reviewed-by: Ira Weiny <ira.weiny@intel.com>

> 
> Matthew Wilcox (Oracle) (11):
>   fix function alignment
>   mm: Pass order to __alloc_pages_nodemask in GFP flags
>   mm: Pass order to __get_free_pages() in GFP flags
>   mm: Pass order to prep_new_page in GFP flags
>   mm: Remove gfp_flags argument from rmqueue_pcplist
>   mm: Pass order to rmqueue in GFP flags
>   mm: Pass order to get_page_from_freelist in GFP flags
>   mm: Pass order to __alloc_pages_cpuset_fallback in GFP flags
>   mm: Pass order to prepare_alloc_pages in GFP flags
>   mm: Pass order to try_to_free_pages in GFP flags
>   mm: Pass order to node_reclaim() in GFP flags
> 
>  arch/x86/Makefile_32.cpu      |  2 +
>  arch/x86/events/intel/ds.c    |  4 +-
>  arch/x86/kvm/vmx/vmx.c        |  4 +-
>  arch/x86/mm/init.c            |  3 +-
>  arch/x86/mm/pgtable.c         |  7 +--
>  drivers/base/devres.c         |  2 +-
>  include/linux/gfp.h           | 57 +++++++++++---------
>  include/linux/migrate.h       |  2 +-
>  include/linux/swap.h          |  2 +-
>  include/trace/events/vmscan.h | 28 +++++-----
>  mm/filemap.c                  |  2 +-
>  mm/gup.c                      |  4 +-
>  mm/hugetlb.c                  |  5 +-
>  mm/internal.h                 |  5 +-
>  mm/khugepaged.c               |  2 +-
>  mm/mempolicy.c                | 30 +++++------
>  mm/migrate.c                  |  2 +-
>  mm/mmu_gather.c               |  2 +-
>  mm/page_alloc.c               | 97 +++++++++++++++++------------------
>  mm/shmem.c                    |  5 +-
>  mm/slub.c                     |  2 +-
>  mm/vmscan.c                   | 26 +++++-----
>  22 files changed, 147 insertions(+), 146 deletions(-)
> 
> -- 
> 2.20.1
> 


  parent reply	other threads:[~2019-05-09  1:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07  4:05 Matthew Wilcox
2019-05-07  4:05 ` [PATCH 01/11] fix function alignment Matthew Wilcox
2019-05-09 10:55   ` Kirill A. Shutemov
2019-05-07  4:06 ` [PATCH 02/11] mm: Pass order to __alloc_pages_nodemask in GFP flags Matthew Wilcox
2019-05-09  1:50   ` Ira Weiny
2019-05-09 13:58     ` Matthew Wilcox
2019-05-09 16:22       ` Weiny, Ira
2019-05-09 10:59   ` Kirill A. Shutemov
2019-05-07  4:06 ` [PATCH 03/11] mm: Pass order to __get_free_pages() " Matthew Wilcox
2019-05-07  4:06 ` [PATCH 04/11] mm: Pass order to prep_new_page " Matthew Wilcox
2019-05-07  4:06 ` [PATCH 05/11] mm: Remove gfp_flags argument from rmqueue_pcplist Matthew Wilcox
2019-05-07  4:06 ` [PATCH 06/11] mm: Pass order to rmqueue in GFP flags Matthew Wilcox
2019-05-07  4:06 ` [PATCH 07/11] mm: Pass order to get_page_from_freelist " Matthew Wilcox
2019-05-07  4:06 ` [PATCH 08/11] mm: Pass order to __alloc_pages_cpuset_fallback " Matthew Wilcox
2019-05-07  4:06 ` [PATCH 09/11] mm: Pass order to prepare_alloc_pages " Matthew Wilcox
2019-05-07  4:06 ` [PATCH 10/11] mm: Pass order to try_to_free_pages " Matthew Wilcox
2019-05-07  4:06 ` [PATCH 11/11] mm: Pass order to node_reclaim() " Matthew Wilcox
2019-05-09  1:58 ` Ira Weiny [this message]
2019-05-09 14:07   ` [RFC 00/11] Remove 'order' argument from many mm functions Matthew Wilcox
2019-05-09 16:48     ` Weiny, Ira
2019-05-09 18:29       ` Matthew Wilcox
2019-05-29 21:44         ` Ira Weiny
2019-05-09 11:07 ` Kirill A. Shutemov
2019-05-14 14:51   ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190509015809.GB26131@iweiny-DESK2.sc.intel.com \
    --to=ira.weiny@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox