ANDROID: Track per-process dmabuf RSS

DMA buffers exist for sharing memory (between processes, drivers, and
hardware) so they are not accounted the same way as user memory present
on a MM's LRUs. Per-process attribution of dmabuf memory is not
maintained by the kernel, so to obtain it from userspace, several files
from procfs and sysfs must be read any time the information is desired.
This process is slow, which can lead to dmabuf accounting information
being out-of-date when it is desired during events like low memory, or
bugreport generation, masking the cause of memory issues.

This patch attributes dmabuf memory to any process that holds a
reference to a buffer. A process can hold a reference to a dmabuf in two
ways:
  1) Through a file descriptor
  2) Though a mapping

A single buffer can be referenced more than once by a single process
with multiple file descriptors for the same buffer, multiple mappings
for the same buffer, or any combination of the two.

The full size of a buffer is effectively pinned until no references
exist from any process, or anywhere else in the kernel such as drivers
that have imported the buffer. Even if a partial mapping of the buffer
is the only reference that exists. Therefore buffer accounting is always
performed in units of the full buffer size, and only once for each
process, regardless of the number and type of references a process has
for a single buffer.

The /proc/<pid>/dmabuf_rss file in procfs now reports the sum of all
buffer sizes referenced by a process. The units are bytes. This allows
userspace to obtain per-process dmabuf accounting information quickly
compared to calculating it from multiple sources in procfs and sysfs.

Note that a dmabuf can be backed by different types of memory such as
system DRAM, GPU VRAM, or others. This patch makes no distinction
between these different types of memory, so on systems with non-unified
memory the reported values should be interpreted with this in mind.

Bug: 424648392
Change-Id: If8135d59a657db96721b07d37dcd9b05eecf2a9f
Signed-off-by: T.J. Mercier <tjmercier@google.com>