On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote:
> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc. memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't
> double-counted.
>
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer. For fd-backed buffers like dma-bufs, hooks
> in
> fdtable.c and fork.c automatically notify memtrack when references are added
> or
> removed from a process's fd table.
>
> This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.
No, with a side of Hell, No. Not to mention anything else,
* descriptor tables do not belong to any specific task_struct and
actions done by one show up in all who share that thing.
* shared descriptor table does not imply belonging to the same
group.
* shared descriptor table can become unshared at any point, invisibly
for that Fine Piece Of Software.
* while we are at it, blocking allocation under several spinlocks
(and with interrupts disabled, for good measure) is generally considered
a bloody bad idea.
That - just from the quick look through that patchset. Bringing task_struct
into the API is already sufficient for a NAK.
