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-kernel@vger.kernel.org, linux-mm@kvack.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 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.
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.
--
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>
next prev parent 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 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 [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
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=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