AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	"Michal Hocko" <mhocko@kernel.org>,
	dri-devel@lists.freedesktop.org, "Roman Gushchin" <guro@fb.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	amd-gfx@lists.freedesktop.org
Subject: Re: [RFC] Per file OOM badness
Date: Tue, 30 Jan 2018 11:40:06 +0100	[thread overview]
Message-ID: <3026d8c5-9313-cb8b-91ef-09c02baf27db@amd.com> (raw)
In-Reply-To: <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net>

Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
> [SNIP]
>> Would it be ok to hang onto potentially arbitrary mmget references
>> essentially forever? If that's ok I think we can do your process based
>> account (minus a few minor inaccuracies for shared stuff perhaps, but no
>> one cares about that).
> Honestly, I think you and Christian are overthinking this. Let's try
> charging the memory to every process which shares a buffer, and go from
> there.

My problem is that this needs to be bullet prove.

For example imagine an application which allocates a lot of BOs, then 
calls fork() and let the parent process die. The file descriptor lives 
on in the child process, but the memory is not accounted against the child.

Otherwise we would allow easy construction of deny of service problems.

To avoid that I think we need to add something like new file_operations 
callbacks which informs a file descriptor that it is going to be used in 
a new process or stopped to be used in a process.

Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-01-30 10:40 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 16:47 [RFC] Per file OOM badness Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 1/4] fs: add OOM badness callback in file_operatrations struct Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 2/4] oom: take per file badness into account Andrey Grodzovsky
     [not found] ` <1516294072-17841-1-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-01-18 16:47   ` [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers Andrey Grodzovsky
2018-01-19  6:01     ` Chunming Zhou
2018-01-18 16:47   ` [PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu Andrey Grodzovsky
2018-01-30  9:24     ` Daniel Vetter
     [not found]       ` <20180130092413.GD25930-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-01-30 12:42         ` Andrey Grodzovsky
2018-01-18 17:00 ` [RFC] Per file OOM badness Michal Hocko
2018-01-18 17:13   ` Michal Hocko
2018-01-18 20:01     ` Eric Anholt
2018-01-19  8:20       ` Michal Hocko
     [not found]         ` <20180119082046.GL6584-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-01-19  8:39           ` Christian König
2018-01-19  9:32             ` Michel Dänzer
2018-01-19  9:58               ` Christian König
     [not found]                 ` <11153f4f-8b9a-5780-6087-bc1e85459584-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-19 10:02                   ` Michel Dänzer
2018-01-19 15:07                     ` Michel Dänzer
2018-01-21  6:50                       ` Eric Anholt
2018-01-19 10:40             ` Michal Hocko
2018-01-19 11:37               ` Christian König
2018-01-19 12:13                 ` Michal Hocko
2018-01-19 12:20                   ` Michal Hocko
2018-01-19 16:54                     ` Christian König
2018-01-23 11:39                       ` Michal Hocko
2018-01-19 16:48                 ` Michel Dänzer
2018-01-19  8:35       ` Christian König
2018-01-19  6:01     ` He, Roger
2018-01-19  8:25       ` Michal Hocko
2018-01-19 10:02         ` roger
2018-01-23 15:27   ` Roman Gushchin
2018-01-23 15:36     ` Michal Hocko
     [not found]       ` <20180123153631.GR1526-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-01-23 16:39         ` Michel Dänzer
2018-01-24  9:28           ` Michal Hocko
2018-01-24 10:27             ` Michel Dänzer
2018-01-24 11:01               ` Michal Hocko
2018-01-24 11:23                 ` Michel Dänzer
     [not found]                   ` <36b49523-792d-45f9-8617-32b6d9d77418-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-01-24 11:50                     ` Michal Hocko
2018-01-24 12:11                       ` Christian König
2018-01-30  9:31                         ` Daniel Vetter
     [not found]                           ` <20180130093145.GE25930-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-01-30  9:43                             ` Michel Dänzer
2018-01-30 10:40                               ` Christian König [this message]
2018-01-30 11:02                                 ` Michel Dänzer
2018-01-30 11:28                                   ` Christian König
2018-01-30 11:34                                     ` Michel Dänzer
2018-01-30 11:36                                       ` Nicolai Hähnle
2018-01-30 11:42                                         ` Michel Dänzer
2018-01-30 11:56                                           ` Christian König
2018-01-30 15:52                                             ` Michel Dänzer
2018-01-30 10:42                               ` Daniel Vetter
2018-01-30 10:48                                 ` Michel Dänzer
2018-01-30 11:35                                   ` Nicolai Hähnle
     [not found]                       ` <20180124115059.GC28465-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-01-24 14:31                         ` Michel Dänzer
2018-01-30  9:29                       ` Michel Dänzer
2018-01-30 10:28                         ` Michal Hocko
     [not found]                           ` <20180130102855.GY21609-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-03-26 14:36                             ` Lucas Stach
     [not found]                               ` <1522074988.1196.1.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2018-04-04  9:09                                 ` Michel Dänzer
2018-04-04  9:36                                   ` Lucas Stach
2018-04-04  9:46                                     ` Michel Dänzer
2018-01-19  5:39 ` He, Roger
2018-01-19  8:17   ` Christian König
2018-01-22 23:23 ` Andrew Morton
     [not found]   ` <20180122152315.749d88f3c91ffce4d70ac450-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2018-01-23  1:59     ` Andrey Grodzovsky

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=3026d8c5-9313-cb8b-91ef-09c02baf27db@amd.com \
    --to=christian.koenig@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=guro@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=michel@daenzer.net \
    /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