From: Matthew Wilcox <willy@infradead.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vladimir Davydov <vdavydov@virtuozzo.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
Dave Hansen <dave.hansen@intel.com>,
Ying Huang <ying.huang@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch] mm: Increase pagevec size on large system
Date: Sat, 27 Jun 2020 04:13:04 +0100 [thread overview]
Message-ID: <20200627031304.GC25039@casper.infradead.org> (raw)
In-Reply-To: <d1cc9f12a8ad6c2a52cb600d93b06b064f2bbc57.1593205965.git.tim.c.chen@linux.intel.com>
On Fri, Jun 26, 2020 at 02:23:03PM -0700, Tim Chen wrote:
> Enlarge the pagevec size to 31 to reduce LRU lock contention for
> large systems.
>
> The LRU lock contention is reduced from 8.9% of total CPU cycles
> to 2.2% of CPU cyles. And the pmbench throughput increases
> from 88.8 Mpages/sec to 95.1 Mpages/sec.
The downside here is that pagevecs are often stored on the stack (eg
truncate_inode_pages_range()) as well as being used for the LRU list.
On a 64-bit system, this increases the stack usage from 128 to 256 bytes
for this array.
I wonder if we could do something where we transform the ones on the
stack to DECLARE_STACK_PAGEVEC(pvec), and similarly DECLARE_LRU_PAGEVEC
the ones used for the LRUs. There's plenty of space in the header to
add an unsigned char sz, delete PAGEVEC_SIZE and make it an variable
length struct.
Or maybe our stacks are now big enough that we just don't care.
What do you think?
next prev parent reply other threads:[~2020-06-27 3:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 21:23 [Patch] mm: Increase pagevec size on large system Tim Chen
2020-06-27 3:13 ` Matthew Wilcox [this message]
2020-06-27 3:47 ` Andrew Morton
2020-06-29 16:57 ` Tim Chen
2020-07-01 0:27 ` Andrew Morton
2020-07-01 10:05 ` 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=20200627031304.GC25039@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=tim.c.chen@linux.intel.com \
--cc=vdavydov@virtuozzo.com \
--cc=ying.huang@intel.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).