From: Michal Hocko <mhocko@suse.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Kalesh Singh <kaleshsingh@google.com>,
surenb@google.com, minchan@kernel.org,
gregkh@linuxfoundation.org, hridya@google.com, jannh@google.com,
kernel-team@android.com, Alexey Dobriyan <adobriyan@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Sumit Semwal <sumit.semwal@linaro.org>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Alexey Gladkov <gladkov.alexey@gmail.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
Michel Lespinasse <walken@google.com>,
Bernd Edlinger <bernd.edlinger@hotmail.de>,
Andrei Vagin <avagin@gmail.com>,
Yafang Shao <laoar.shao@gmail.com>, Hui Su <sh_def@163.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf_fds
Date: Wed, 27 Jan 2021 12:02:08 +0100 [thread overview]
Message-ID: <YBFIMIR2FXoYDd+0@dhcp22.suse.cz> (raw)
In-Reply-To: <6b314cf2-99f0-8e63-acc7-edebe2ca97d7@amd.com>
On Wed 27-01-21 11:53:55, Christian König wrote:
[...]
> In general processes are currently not held accountable for memory they
> reference through their file descriptors. DMA-buf is just one special case.
True
> In other words you can currently do something like this
>
> fd = memfd_create("test", 0);
> while (1)
> write(fd, buf, 1024);
>
> and the OOM killer will terminate random processes, but never the one
> holding the memfd reference.
memfd is just shmem under cover, no? And that means that the memory gets
accounted to MM_SHMEMPAGES. But you are right that this in its own
doesn't help much if the fd is shared and the memory stays behind a
killed victim.
But I do agree with you that there are resources which are bound to a
process life time but the oom killer has no idea about those as they are
not accounted on a per process level and/or oom_badness doesn't take
them into consideration.
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: linux-doc@vger.kernel.org, Szabolcs Nagy <szabolcs.nagy@arm.com>,
dri-devel@lists.freedesktop.org,
Yafang Shao <laoar.shao@gmail.com>,
Kalesh Singh <kaleshsingh@google.com>, Hui Su <sh_def@163.com>,
Michel Lespinasse <walken@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
kernel-team@android.com, Alexey Dobriyan <adobriyan@gmail.com>,
linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
jannh@google.com, linaro-mm-sig@lists.linaro.org,
linux-fsdevel@vger.kernel.org,
Bernd Edlinger <bernd.edlinger@hotmail.de>,
surenb@google.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, minchan@kernel.org,
Andrei Vagin <avagin@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexey Gladkov <gladkov.alexey@gmail.com>,
hridya@google.com, Andrew Morton <akpm@linux-foundation.org>,
linux-api@vger.kernel.org
Subject: Re: [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf_fds
Date: Wed, 27 Jan 2021 12:02:08 +0100 [thread overview]
Message-ID: <YBFIMIR2FXoYDd+0@dhcp22.suse.cz> (raw)
In-Reply-To: <6b314cf2-99f0-8e63-acc7-edebe2ca97d7@amd.com>
On Wed 27-01-21 11:53:55, Christian König wrote:
[...]
> In general processes are currently not held accountable for memory they
> reference through their file descriptors. DMA-buf is just one special case.
True
> In other words you can currently do something like this
>
> fd = memfd_create("test", 0);
> while (1)
> write(fd, buf, 1024);
>
> and the OOM killer will terminate random processes, but never the one
> holding the memfd reference.
memfd is just shmem under cover, no? And that means that the memory gets
accounted to MM_SHMEMPAGES. But you are right that this in its own
doesn't help much if the fd is shared and the memory stays behind a
killed victim.
But I do agree with you that there are resources which are bound to a
process life time but the oom killer has no idea about those as they are
not accounted on a per process level and/or oom_badness doesn't take
them into consideration.
--
Michal Hocko
SUSE Labs
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-01-27 11:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 22:51 [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf_fds Kalesh Singh
2021-01-26 22:51 ` Kalesh Singh
2021-01-27 9:05 ` Michal Hocko
2021-01-27 9:05 ` Michal Hocko
2021-01-27 10:53 ` Christian König
2021-01-27 10:53 ` Christian König
2021-01-27 11:02 ` Michal Hocko [this message]
2021-01-27 11:02 ` Michal Hocko
2021-01-27 11:08 ` Christian König
2021-01-27 11:08 ` Christian König
2021-01-27 11:23 ` Michal Hocko
2021-01-27 11:23 ` Michal Hocko
2021-01-27 10:47 ` Jann Horn
2021-01-27 10:47 ` Jann Horn
2021-01-27 10:57 ` Michal Hocko
2021-01-27 10:57 ` Michal Hocko
2021-01-27 11:01 ` Christian König
2021-01-27 11:01 ` Christian König
2021-01-27 11:27 ` Michal Hocko
2021-01-27 11:27 ` Michal Hocko
2021-01-28 10:01 ` Pekka Paalanen
2021-01-28 10:01 ` Pekka Paalanen
2021-01-29 12:18 ` Christian König
2021-01-29 14:13 ` Pekka Paalanen
2021-01-29 14:17 ` Simon Ser
2021-01-29 14:22 ` Christian König
2021-02-03 10:23 ` Daniel Vetter
2021-02-03 10:23 ` Daniel Vetter
2021-01-27 17:16 ` Kalesh Singh
2021-01-27 17:16 ` Kalesh Singh
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=YBFIMIR2FXoYDd+0@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@gmail.com \
--cc=bernd.edlinger@hotmail.de \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=daniel.m.jordan@oracle.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ebiederm@xmission.com \
--cc=gladkov.alexey@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hridya@google.com \
--cc=jannh@google.com \
--cc=kaleshsingh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=laoar.shao@gmail.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=minchan@kernel.org \
--cc=sh_def@163.com \
--cc=sumit.semwal@linaro.org \
--cc=surenb@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=walken@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.