From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable
Date: Wed, 31 Oct 2018 07:19:21 -0700
Message-ID: <039b2768-39ff-6196-9615-1f0302ee3e0e@intel.com>
References: <20181031081945.207709-1-vovoy@chromium.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20181031081945.207709-1-vovoy@chromium.org>
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
To: owner-linux-mm@kvack.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.orglinux-mm@kvack.org
Cc: Kuo-Hsin Yang <vovoy@chromium.org>, Chris Wilson <chris@chris-wilson.co.uk>, Michal Hocko <mhocko@suse.com>, Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>, Andrew Morton <akpm@linux-foundation.org>
List-Id: intel-gfx@lists.freedesktop.org

On 10/31/18 1:19 AM, owner-linux-mm@kvack.org wrote:
> -These are currently used in two places in the kernel:
> +These are currently used in three places in the kernel:
>  
>   (1) By ramfs to mark the address spaces of its inodes when they are created,
>       and this mark remains for the life of the inode.
> @@ -154,6 +154,8 @@ These are currently used in two places in the kernel:
>       swapped out; the application must touch the pages manually if it wants to
>       ensure they're in memory.
>  
> + (3) By the i915 driver to mark pinned address space until it's unpinned.

mlock() and ramfs usage are pretty easy to track down.  /proc/$pid/smaps
or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
show us ramfs the extent of pinned memory.

With these, if we see "Unevictable" in meminfo bump up, we at least have
a starting point to find the cause.

Do we have an equivalent for i915?