Am 12.10.2016 um 01:50 schrieb Ruchi Kandoi:
> 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.
We have run into similar problems before. Because of this I alr
On 10/11/2016 04:50 PM, Ruchi Kandoi wrote:
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address
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
> ta
On Tue, Oct 11, 2016 at 7:50 PM, Ruchi Kandoi wrote:
> This patchstack introduces a new "memtrack" module for tracking and accounting
> memory exported to userspace as shared buffers, like dma-buf fds or GEM
> handles.
btw, I wouldn't care much about the non-dmabuf case.. dri2/flink is
kind of l
This patchstack introduces a new "memtrack" module for tracking and accounting
memory exported to userspace as shared buffers, like dma-buf fds or GEM handles.
Any process holding a reference to these buffers will keep the kernel from
reclaiming its backing pages. mm counters don't provide a comp
