All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vovo Yang <vovoy@chromium.org>
To: mhocko@kernel.org
Cc: dave.hansen@intel.com, linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, linux-mm@kvack.org,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	peterz@infradead.org, akpm@linux-foundation.org
Subject: Re: [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable
Date: Thu, 1 Nov 2018 19:28:46 +0800	[thread overview]
Message-ID: <CAEHM+4pSkv_fD3Yb2KX1xFrOmRHU1e=+wCBrCyLAAMBG3zP75w@mail.gmail.com> (raw)
In-Reply-To: <20181031164231.GQ32673@dhcp22.suse.cz>

On Thu, Nov 1, 2018 at 12:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 31-10-18 07:40:14, Dave Hansen wrote:
> > Didn't we create the unevictable lists in the first place because
> > scanning alone was observed to be so expensive in some scenarios?
>
> Yes, that is the case. I might just misunderstood the code I thought
> those pages were already on the LRU when unevictable flag was set and
> we would only move these pages to the unevictable list lazy during the
> reclaim. If the flag is set at the time when the page is added to the
> LRU then it should get to the proper LRU list right away. But then I do
> not understand the test results from previous run at all.

"gem_syslatency -t 120 -b -m" allocates a lot of anon pages, it consists of
these looping threads:
  * ncpu threads to alloc i915 shmem buffers, these buffers are freed by i915
shrinker.
  * ncpu threads to mmap, write, munmap an 2 MiB mapping.
  * 1 thread to cat all files to /dev/null

Without the unevictable patch, after rebooting and running
"gem_syslatency -t 120 -b -m", I got these custom vmstat:
  pgsteal_kswapd_anon 29261
  pgsteal_kswapd_file 1153696
  pgsteal_direct_anon 255
  pgsteal_direct_file 13050
  pgscan_kswapd_anon 14524536
  pgscan_kswapd_file 1488683
  pgscan_direct_anon 1702448
  pgscan_direct_file 25849

And meminfo shows large anon lru size during test.
  # cat /proc/meminfo | grep -i "active("
  Active(anon):     377760 kB
  Inactive(anon):  3195392 kB
  Active(file):      19216 kB
  Inactive(file):    16044 kB

With this patch, the custom vmstat after test:
  pgsteal_kswapd_anon 74962
  pgsteal_kswapd_file 903588
  pgsteal_direct_anon 4434
  pgsteal_direct_file 14969
  pgscan_kswapd_anon 2814791
  pgscan_kswapd_file 1113676
  pgscan_direct_anon 526766
  pgscan_direct_file 32432

The anon pgscan count is reduced.

WARNING: multiple messages have this Message-ID (diff)
From: Vovo Yang <vovoy@chromium.org>
To: mhocko@kernel.org
Cc: linux-mm@kvack.org, peterz@infradead.org,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dave.hansen@intel.com, akpm@linux-foundation.org
Subject: Re: [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable
Date: Thu, 1 Nov 2018 19:28:46 +0800	[thread overview]
Message-ID: <CAEHM+4pSkv_fD3Yb2KX1xFrOmRHU1e=+wCBrCyLAAMBG3zP75w@mail.gmail.com> (raw)
In-Reply-To: <20181031164231.GQ32673@dhcp22.suse.cz>

On Thu, Nov 1, 2018 at 12:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 31-10-18 07:40:14, Dave Hansen wrote:
> > Didn't we create the unevictable lists in the first place because
> > scanning alone was observed to be so expensive in some scenarios?
>
> Yes, that is the case. I might just misunderstood the code I thought
> those pages were already on the LRU when unevictable flag was set and
> we would only move these pages to the unevictable list lazy during the
> reclaim. If the flag is set at the time when the page is added to the
> LRU then it should get to the proper LRU list right away. But then I do
> not understand the test results from previous run at all.

"gem_syslatency -t 120 -b -m" allocates a lot of anon pages, it consists of
these looping threads:
  * ncpu threads to alloc i915 shmem buffers, these buffers are freed by i915
shrinker.
  * ncpu threads to mmap, write, munmap an 2 MiB mapping.
  * 1 thread to cat all files to /dev/null

Without the unevictable patch, after rebooting and running
"gem_syslatency -t 120 -b -m", I got these custom vmstat:
  pgsteal_kswapd_anon 29261
  pgsteal_kswapd_file 1153696
  pgsteal_direct_anon 255
  pgsteal_direct_file 13050
  pgscan_kswapd_anon 14524536
  pgscan_kswapd_file 1488683
  pgscan_direct_anon 1702448
  pgscan_direct_file 25849

And meminfo shows large anon lru size during test.
  # cat /proc/meminfo | grep -i "active("
  Active(anon):     377760 kB
  Inactive(anon):  3195392 kB
  Active(file):      19216 kB
  Inactive(file):    16044 kB

With this patch, the custom vmstat after test:
  pgsteal_kswapd_anon 74962
  pgsteal_kswapd_file 903588
  pgsteal_direct_anon 4434
  pgsteal_direct_file 14969
  pgscan_kswapd_anon 2814791
  pgscan_kswapd_file 1113676
  pgscan_direct_anon 526766
  pgscan_direct_file 32432

The anon pgscan count is reduced.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-11-01 11:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31  8:19 [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable Kuo-Hsin Yang
2018-10-31  8:19 ` Kuo-Hsin Yang
2018-10-31  9:41 ` Chris Wilson
2018-10-31  9:41   ` Chris Wilson
2018-10-31  9:41   ` Chris Wilson
2018-10-31 10:42   ` Vovo Yang
2018-11-01 12:20   ` Chris Wilson
2018-11-01 12:20     ` Chris Wilson
2018-11-01 12:20     ` Chris Wilson
2018-10-31 11:05 ` ✗ Fi.CI.CHECKPATCH: warning for mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev2) Patchwork
2018-10-31 11:22 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-31 14:19 ` [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable Dave Hansen
2018-10-31 14:19   ` Dave Hansen
2018-11-01 12:06   ` Vovo Yang
2018-11-01 12:06     ` Vovo Yang
2018-11-01 14:30     ` Dave Hansen
2018-11-02 13:22       ` Vovo Yang
2018-11-02 14:05         ` Dave Hansen
2018-11-05 11:24           ` Kuo-Hsin Yang
2018-10-31 14:24 ` Michal Hocko
2018-10-31 14:40   ` Dave Hansen
2018-10-31 14:40     ` Dave Hansen
2018-10-31 16:42     ` Michal Hocko
2018-10-31 16:42       ` Michal Hocko
2018-11-01 11:28       ` Vovo Yang [this message]
2018-11-01 11:28         ` Vovo Yang
2018-11-01 13:09         ` Michal Hocko
2018-11-01 13:09           ` Michal Hocko
2018-11-02 12:35           ` Vovo Yang
2018-11-02 18:26             ` Michal Hocko
2018-11-02 18:26               ` Michal Hocko
2018-10-31 14:28 ` ✓ Fi.CI.IGT: success for mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev2) Patchwork

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='CAEHM+4pSkv_fD3Yb2KX1xFrOmRHU1e=+wCBrCyLAAMBG3zP75w@mail.gmail.com' \
    --to=vovoy@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=dave.hansen@intel.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=mhocko@kernel.org \
    --cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.