AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolai Hähnle" <nhaehnle@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	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:36:37 +0100	[thread overview]
Message-ID: <82d5894f-f4ea-98cc-068a-5d470f5267df@gmail.com> (raw)
In-Reply-To: <e511ba10-7032-36cc-f22c-2f6bb05f9f6e@daenzer.net>

On 30.01.2018 12:34, Michel Dänzer wrote:
> On 2018-01-30 12:28 PM, Christian König wrote:
>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>>> On 2018-01-30 11:40 AM, Christian König wrote:
>>>> 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.
>>> 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.

Existing protocols pass DRM fds between processes though, don't they?

Not child processes perhaps, but special-casing that seems like awful 
design.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-01-30 11:36 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
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 [this message]
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=82d5894f-f4ea-98cc-068a-5d470f5267df@gmail.com \
    --to=nhaehnle@gmail.com \
    --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 \
    --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