Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
Subject: Re: [PATCH 3/4] drm/gem: adjust per file OOM badness on handling
 buffers
To:     Andrey Grodzovsky <andrey.grodzovsky@amd.com>,
        <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
        <dri-devel@lists.freedesktop.org>, <amd-gfx@lists.freedesktop.org>
CC:     <Christian.Koenig@amd.com>
References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com>
 <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com>
From:   Chunming Zhou <zhoucm1@amd.com>
Message-ID: <bc332280-b60d-308b-5a52-8131590c06b7@amd.com>
Date:   Fri, 19 Jan 2018 14:01:32 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2018 06:01:40.1157
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7283b251-0be2-44e6-4553-08d55f021bc6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXCHOV02.amd.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1444
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 2018年01月19日 00:47, Andrey Grodzovsky wrote:
> Large amounts of VRAM are usually not CPU accessible, so they are not mapped
> into the processes address space. But since the device drivers usually support
> swapping buffers from VRAM to system memory we can still run into an out of
> memory situation when userspace starts to allocate to much.
>
> This patch gives the OOM another hint which process is
> holding how many resources.
>
> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> ---
>   drivers/gpu/drm/drm_file.c | 12 ++++++++++++
>   drivers/gpu/drm/drm_gem.c  |  8 ++++++++
>   include/drm/drm_file.h     |  4 ++++
>   3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index b3c6e99..626cc76 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -747,3 +747,15 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
>   	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>   }
>   EXPORT_SYMBOL(drm_send_event);
> +
> +long drm_oom_badness(struct file *f)
> +{
> +
> +	struct drm_file *file_priv = f->private_data;
> +
> +	if (file_priv)
> +		return atomic_long_read(&file_priv->f_oom_badness);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_oom_badness);
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 01f8d94..ffbadc8 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -264,6 +264,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
>   		drm_gem_remove_prime_handles(obj, file_priv);
>   	drm_vma_node_revoke(&obj->vma_node, file_priv);
>   
> +	atomic_long_sub(obj->size >> PAGE_SHIFT,
> +				&file_priv->f_oom_badness);
> +
>   	drm_gem_object_handle_put_unlocked(obj);
>   
>   	return 0;
> @@ -299,6 +302,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
>   	idr_remove(&filp->object_idr, handle);
>   	spin_unlock(&filp->table_lock);
>   
> +	atomic_long_sub(obj->size >> PAGE_SHIFT, &filp->f_oom_badness);
> +
>   	return 0;
>   }
>   EXPORT_SYMBOL(drm_gem_handle_delete);
> @@ -417,6 +422,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
>   	}
>   
>   	*handlep = handle;
> +
> +	atomic_long_add(obj->size >> PAGE_SHIFT,
> +				&file_priv->f_oom_badness);
For VRAM case, it should be counted only when vram bo is evicted to 
system memory.
For example, vram total is 8GB, system memory total is 8GB, one 
application allocates 7GB vram and 7GB system memory, which is allowed, 
but if following your idea, then this application will be killed by OOM, 
right?

Regards,
David Zhou
>   	return 0;
>   
>   err_revoke:
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 0e0c868..ac3aa75 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -317,6 +317,8 @@ struct drm_file {
>   
>   	/* private: */
>   	unsigned long lock_count; /* DRI1 legacy lock count */
> +
> +	atomic_long_t		f_oom_badness;
>   };
>   
>   /**
> @@ -378,4 +380,6 @@ void drm_event_cancel_free(struct drm_device *dev,
>   void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
>   void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
>   
> +long drm_oom_badness(struct file *f);
> +
>   #endif /* _DRM_FILE_H_ */