linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Matthew Wilcox <willy@infradead.org>,
	Mel Gorman <mgorman@suse.de>, Kees Cook <keescook@chromium.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Iurii Zaikin <yzaikin@google.com>,
	"Kleen, Andi" <andi.kleen@intel.com>,
	"Chen, Tim C" <tim.c.chen@intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] mm: adjust vm_committed_as_batch according to vm overcommit policy
Date: Fri, 15 May 2020 19:26:27 +0800	[thread overview]
Message-ID: <20200515112627.GF69177@shbuild999.sh.intel.com> (raw)
In-Reply-To: <20200515090821.GO29153@dhcp22.suse.cz>

On Fri, May 15, 2020 at 05:08:21PM +0800, Michal Hocko wrote:
> > > > +void mm_compute_batch(void)
> > > >  {
> > > >  	u64 memsized_batch;
> > > >  	s32 nr = num_present_cpus();
> > > >  	s32 batch = max_t(s32, nr*2, 32);
> > > > -
> > > > -	/* batch size set to 0.4% of (total memory/#cpus), or max int32 */
> > > > -	memsized_batch = min_t(u64, (totalram_pages()/nr)/256, 0x7fffffff);
> > > > +	unsigned long ram_pages = totalram_pages();
> > > > +
> > > > +	/*
> > > > +	 * For policy of OVERCOMMIT_NEVER, set batch size to 0.4%
> > > > +	 * of (total memory/#cpus), and lift it to 6.25% for other
> > > > +	 * policies to easy the possible lock contention for percpu_counter
> > > > +	 * vm_committed_as, while the max limit is INT_MAX
> > > > +	 */
> > > > +	if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
> > > > +		memsized_batch = min_t(u64, ram_pages/nr/256, INT_MAX);
> > > > +	else
> > > > +		memsized_batch = min_t(u64, ram_pages/nr/16, INT_MAX);
> > 
> > Also as you mentioned there are real-world work loads with big mmap
> > size and multi-threading, can we lift it even further ?
> > 	memsized_batch = min_t(u64, ram_pages/nr/4, INT_MAX)
> 
> Try to measure those and see what numbers look like.

With the same benchmark, for the 16X lifting in this patch, about
1/3 of the test platforms (servers, desktops, laptops) will show
improvements (up to 20X for servers, much less on platform with
fewer CPUs). 

If we further lift it to 64X, most of the test platforms will
show improvements. 

Thanks,
Feng

  reply	other threads:[~2020-05-15 11:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08  7:25 [PATCH 0/3] make vm_committed_as_batch aware of " Feng Tang
2020-05-08  7:25 ` [PATCH 1/3] proc/meminfo: avoid open coded reading of vm_committed_as Feng Tang
2020-05-15  7:22   ` Michal Hocko
2020-05-08  7:25 ` [PATCH 2/3] mm/util.c: make vm_memory_committed() more accurate Feng Tang
2020-05-15  7:23   ` Michal Hocko
2020-05-15  8:11     ` Feng Tang
2020-05-15  9:04       ` Michal Hocko
2020-05-15 13:01         ` Feng Tang
2020-05-08  7:25 ` [PATCH 3/3] mm: adjust vm_committed_as_batch according to vm overcommit policy Feng Tang
2020-05-08 11:24   ` Matthew Wilcox
2020-05-08 12:33     ` Feng Tang
2020-05-15  7:41   ` Michal Hocko
2020-05-15  8:02     ` Feng Tang
2020-05-15  9:08       ` Michal Hocko
2020-05-15 11:26         ` Feng Tang [this message]
2020-05-15  7:44   ` Michal Hocko
2020-05-15  8:38     ` Feng Tang
2020-05-21 21:27 ` [PATCH 0/3] make vm_committed_as_batch aware of " Qian Cai
2020-05-26 18:14   ` Qian Cai
2020-05-27  1:14     ` Andi Kleen
2020-05-27  1:43       ` Feng Tang
2020-05-27  1:46     ` Feng Tang
2020-05-27  2:25       ` Qian Cai
2020-05-27 10:46         ` Feng Tang
2020-05-27 12:05           ` Qian Cai
2020-05-27 13:33             ` Feng Tang
2020-05-27 15:42               ` Qian Cai
2020-05-28 14:18           ` Qian Cai
2020-05-28 15:10             ` Feng Tang
2020-05-28 15:21               ` Kleen, Andi
2020-05-29 15:43                 ` Feng Tang
2020-05-29 15:50                   ` Andi Kleen
2020-05-29 16:04                     ` Feng Tang
2020-05-28 15:48               ` Michal Hocko

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=20200515112627.GF69177@shbuild999.sh.intel.com \
    --to=feng.tang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=tim.c.chen@intel.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=yzaikin@google.com \
    --subject='Re: [PATCH 3/3] mm: adjust vm_committed_as_batch according to vm overcommit policy' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox