linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: christian.koenig@amd.com, Michal Hocko <mhocko@kernel.org>,
	Roman Gushchin <guro@fb.com>
Cc: linux-mm@kvack.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org
Subject: Re: [RFC] Per file OOM badness
Date: Tue, 30 Jan 2018 12:34:18 +0100	[thread overview]
Message-ID: <e511ba10-7032-36cc-f22c-2f6bb05f9f6e@daenzer.net> (raw)
In-Reply-To: <dce6d244-36c7-7452-97f5-7437bd78cfcc@gmail.com>

On 2018-01-30 12:28 PM, Christian KA?nig wrote:
> Am 30.01.2018 um 12:02 schrieb Michel DA?nzer:
>> On 2018-01-30 11:40 AM, Christian KA?nig wrote:
>>> Am 30.01.2018 um 10:43 schrieb Michel DA?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.
>> What exactly are you referring to by "the file descriptor" here?
> 
> The file descriptor used to identify the connection to the driver. In
> other words our drm_file structure in the kernel.
> 
>> What happens to BO handles in general in this case? If both parent and
>> child process keep the same handle for the same BO, one of them
>> destroying the handle will result in the other one not being able to use
>> it anymore either, won't it?
> Correct.
> 
> That usage is actually not useful at all, but we already had
> applications which did exactly that by accident.
> 
> Not to mention that somebody could do it on purpose.

Can we just prevent child processes from using their parent's DRM file
descriptors altogether? Allowing it seems like a bad idea all around.


-- 
Earthling Michel DA?nzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 16:47 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
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
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
2018-01-19  8:39         ` Christian König
2018-01-19  9:32           ` Michel Dänzer
2018-01-19  9:58             ` Christian König
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
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
2018-01-24 11:50                 ` Michal Hocko
2018-01-24 12:11                   ` Christian König
2018-01-30  9:31                     ` Daniel Vetter
2018-01-30  9:43                       ` Michel Dänzer
2018-01-30 10:40                         ` Christian König
2018-01-30 11:02                           ` Michel Dänzer
2018-01-30 11:28                             ` Christian König
2018-01-30 11:34                               ` Michel Dänzer [this message]
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
2018-01-24 14:31                   ` Michel Dänzer
2018-01-30  9:29                   ` Michel Dänzer
2018-01-30 10:28                     ` Michal Hocko
2018-03-26 14:36                       ` Lucas Stach
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
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=e511ba10-7032-36cc-f22c-2f6bb05f9f6e@daenzer.net \
    --to=michel@daenzer.net \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --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 \
    /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