Am 27.01.21 um 11:57 schrieb Michal Hocko:
On Wed 27-01-21 11:47:29, Jann Horn wrote:
+jeffv from Android
On Tue, Jan 26, 2021 at 11:51 PM Kalesh Singh <kaleshsingh@xxxxxxxxxx> wrote:
In order to measure how much memory a process actually consumes, it is
necessary to include the DMA buffer sizes for that process in the memory
accounting. Since the handle to DMA buffers are raw FDs, it is important
to be able to identify which processes have FD references to a DMA buffer.
Or you could try to let the DMA buffer take a reference on the
mm_struct and account its size into the mm_struct? That would probably
be nicer to work with than having to poke around in procfs separately
for DMA buffers.
Yes that would make some sense to me as well but how do you know that
the process actually uses a buffer? If it mmaps it then you already have
that information via /proc/<pid>/maps. My understanding of dma-buf is
really coarse but my impression is that you can consume the memory via
standard read syscall as well. How would you account for that.
Somewhat correct. This interface here really doesn't make sense since
the file descriptor representation of DMA-buf is only meant to be used
for short term usage.
E.g. the idea is that you can export a DMA-buf fd from your device
driver, transfer that to another process and then import it again into a
device driver.
Keeping a long term reference to a DMA-buf fd sounds like a design bug
in userspace to me.
[...]
Skipping over a large part of your response but I do agree that the
interface is really elaborate to drill down to the information.
I'm not convinced that introducing a new procfs file for this is the
right way to go. And the idea of having to poke into multiple
different files in procfs and in sysfs just to be able to compute a
proper memory usage score for a process seems weird to me. "How much
memory is this process using" seems like the kind of question the
kernel ought to be able to answer (and the kernel needs to be able to
answer somewhat accurately so that its own OOM killer can do its job
properly)?
Well, shared buffers are tricky but it is true that we already consider
shmem in badness so this wouldn't go out of line. Kernel oom killer
could be more clever with these special fds though and query for buffer
size directly.
Some years ago I've proposed an change to improve the OOM killer to take
into account how much memory is reference through special file
descriptors like device drivers or DMA-buf.
But that never want anywhere because of concerns that this would add to
much overhead to the OOM killer.
Regards,
Christian.
