From: Michal Hocko <mhocko@kernel.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kuo-Hsin Yang <vovoy@chromium.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-mm@kvack.org, akpm@linux-foundation.org,
peterz@infradead.org, dave.hansen@intel.com, corbet@lwn.net,
hughd@google.com, joonas.lahtinen@linux.intel.com,
marcheu@chromium.org, hoegsberg@chromium.org
Subject: Re: [PATCH 2/2] drm/i915: Mark pinned shmemfs pages as unevictable
Date: Thu, 18 Oct 2018 10:15:52 +0200 [thread overview]
Message-ID: <20181018081552.GZ18839@dhcp22.suse.cz> (raw)
In-Reply-To: <153984580501.19935.11456945882099910977@skylake-alporthouse-com>
On Thu 18-10-18 07:56:45, Chris Wilson wrote:
> Quoting Chris Wilson (2018-10-16 19:31:06)
> > Fwiw, the shmem_unlock_mapping() call feels quite expensive, almost
> > nullifying the advantage gained from not walking the lists in reclaim.
> > I'll have better numbers in a couple of days.
>
> Using a test ("igt/benchmarks/gem_syslatency -t 120 -b -m" on kbl)
> consisting of cycletest with a background load of trying to allocate +
> populate 2MiB (to hit thp) while catting all files to /dev/null, the
> result of using mapping_set_unevictable is mixed.
I haven't really read through your report completely yet but I wanted to
point out that the above test scenario is unlikely show the real effect of
the LRU scanning overhead because shmem pages do live on the anonymous
LRU list. With a plenty of file page cache available we do not even scan
anonymous LRU lists. You would have to generate a swapout workload to
test this properly.
On the other hand if mapping_set_unevictable has really a measurably bad
performance impact then this is probably not worth much because most
workloads are swap modest.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-10-18 8:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 17:42 [PATCH 0/2] shmem, " Kuo-Hsin Yang
2018-10-16 17:42 ` [PATCH 1/2] shmem: export shmem_unlock_mapping Kuo-Hsin Yang
2018-10-16 17:43 ` [PATCH 2/2] drm/i915: Mark pinned shmemfs pages as unevictable Kuo-Hsin Yang
2018-10-16 18:21 ` Michal Hocko
2018-10-16 18:31 ` Chris Wilson
2018-10-16 19:13 ` Michal Hocko
2018-10-18 6:56 ` Chris Wilson
2018-10-18 8:15 ` Michal Hocko [this message]
2018-10-17 8:58 ` [PATCH v2] shmem, drm/i915: mark " Kuo-Hsin Yang
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=20181018081552.GZ18839@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=hoegsberg@chromium.org \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcheu@chromium.org \
--cc=peterz@infradead.org \
--cc=vovoy@chromium.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