From: Andrew Morton <akpm@linux-foundation.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>,
Mel Gorman <mgorman@techsingularity.net>,
Vladimir Davydov <vdavydov@virtuozzo.com>,
Konstantin Khlebnikov <koct9i@gmail.com>
Subject: Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting
Date: Wed, 10 Feb 2016 13:28:18 -0800 [thread overview]
Message-ID: <20160210132818.589451dbb5eafae3fdb4a7ec@linux-foundation.org> (raw)
In-Reply-To: <1455127253.715.36.camel@schen9-desk2.jf.intel.com>
On Wed, 10 Feb 2016 10:00:53 -0800 Tim Chen <tim.c.chen@linux.intel.com> wrote:
> On Wed, 2016-02-10 at 17:52 +0300, Andrey Ryabinin wrote:
> > Currently we use percpu_counter for accounting committed memory. Change
> > of committed memory on more than vm_committed_as_batch pages leads to
> > grab of counter's spinlock. The batch size is quite small - from 32 pages
> > up to 0.4% of the memory/cpu (usually several MBs even on large machines).
> >
> > So map/munmap of several MBs anonymous memory in multiple processes leads
> > to high contention on that spinlock.
> >
> > Instead of percpu_counter we could use ordinary per-cpu variables.
> > Dump test case (8-proccesses running map/munmap of 4MB,
> > vm_committed_as_batch = 2MB on test setup) showed 2.5x performance
> > improvement.
> >
> > The downside of this approach is slowdown of vm_memory_committed().
> > However, it doesn't matter much since it usually is not in a hot path.
> > The only exception is __vm_enough_memory() with overcommit set to
> > OVERCOMMIT_NEVER. In that case brk1 test from will-it-scale benchmark
> > shows 1.1x - 1.3x performance regression.
> >
> > So I think it's a good tradeoff. We've got significantly increased
> > scalability for the price of some overhead in vm_memory_committed().
>
> It is a trade off between the counter read speed vs the counter update
> speed. With this change the reading of the counter is slower
> because we need to sum over all the cpus each time we need the counter
> value. So this read overhead will grow with the number of cpus and may
> not be a good tradeoff for that case.
>
> Wonder if you have tried to tweak the batch size of per cpu counter
> and make it a little larger?
If a process is unmapping 4MB then it's pretty crazy for us to be
hitting the percpu_counter 32 separate times for that single operation.
Is there some way in which we can batch up the modifications within the
caller and update the counter less frequently? Perhaps even in a
single hit?
--
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>
next prev parent reply other threads:[~2016-02-10 21:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 14:52 [PATCH 1/3] mm: move max_map_count bits into mm.h Andrey Ryabinin
2016-02-10 14:52 ` [PATCH 2/3] mm: dedupclicate memory overcommitment code Andrey Ryabinin
2016-02-10 14:52 ` [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting Andrey Ryabinin
2016-02-10 17:46 ` Konstantin Khlebnikov
2016-02-11 13:36 ` Andrey Ryabinin
2016-02-11 16:57 ` Tim Chen
2016-02-10 18:00 ` Tim Chen
2016-02-10 21:28 ` Andrew Morton [this message]
2016-02-11 0:24 ` Tim Chen
2016-02-11 13:54 ` Andrey Ryabinin
2016-02-11 18:20 ` Tim Chen
2016-02-11 19:45 ` Dave Hansen
2016-02-11 20:51 ` Andrew Morton
2016-02-11 21:18 ` Tim Chen
2016-02-12 12:24 ` Andrey Ryabinin
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=20160210132818.589451dbb5eafae3fdb4a7ec@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ak@linux.intel.com \
--cc=aryabinin@virtuozzo.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=tim.c.chen@linux.intel.com \
--cc=vdavydov@virtuozzo.com \
/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;
as well as URLs for NNTP newsgroup(s).