From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs and numa - needing drop_caches to keep speed up
Date: Fri, 14 Oct 2016 08:48:30 -0400 [thread overview]
Message-ID: <56016a39-5ebf-5f3f-f07d-b4557a131568@gmail.com> (raw)
In-Reply-To: <818cbe6c-fe7a-7542-3bc8-76b205c9b80b@profihost.ag>
On 2016-10-14 02:28, Stefan Priebe - Profihost AG wrote:
> Hello list,
>
> while running the same workload on two machines (single xeon and a dual
> xeon) both with 64GB RAM.
>
> I need to run echo 3 >/proc/sys/vm/drop_caches every 15-30 minutes to
> keep the speed as good as on the non numa system. I'm not sure whether
> this is related to numa.
>
> Is there any sysctl parameter to tune?
>
> Tested with vanilla v4.8.1
This may sound odd, but does echoing 1 or 2 to /proc/sys/vm/drop_caches
help at all, or is it just 3? The value itself is actually a bit-field
with just two bits defined. 1 just drops the page-cache, while 2 just
drops freeable SLAB objects, and 3 drops both. The thing is, both have
an impact when dealing with filesystems (page-cache contains cached file
contents, while freeable SLAB objects includes cached dentries and
inodes), so knowing whether one or the other or only both is what's
helping things can help diagnose this further.
Regardless of that, you might try adjusting vm.vfs_cache_pressure.
Increasing that will make the page-cache reclaim more aggressive, while
decreasing it will make it less aggressive. It defaults to 100, and I
wouldn't suggest setting it below 50 or above about 150. Keep in mind
that increasing that will mean you're likely to put more load on the
storage devices.
prev parent reply other threads:[~2016-10-14 12:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-14 6:28 btrfs and numa - needing drop_caches to keep speed up Stefan Priebe - Profihost AG
2016-10-14 12:26 ` Julian Taylor
2016-10-14 13:19 ` Stefan Priebe - Profihost AG
2016-10-14 14:06 ` Stefan Priebe - Profihost AG
2016-10-14 12:48 ` Austin S. Hemmelgarn [this message]
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=56016a39-5ebf-5f3f-f07d-b4557a131568@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=s.priebe@profihost.ag \
/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).