From: Dave Hansen <dave.hansen@linux.intel.com>
To: Ruchi Kandoi <kandoiruchi@google.com>,
gregkh@linuxfoundation.org, arve@android.com,
riandrews@android.com, sumit.semwal@linaro.org, arnd@arndb.de,
labbott@redhat.com, viro@zeniv.linux.org.uk,
jlayton@poochiereds.net, bfields@fieldses.org, mingo@redhat.com,
peterz@infradead.org, akpm@linux-foundation.org,
keescook@chromium.org, mhocko@suse.com, oleg@redhat.com,
john.stultz@linaro.org, mguzik@redhat.com, jdanis@google.com,
adobriyan@gmail.com, ghackmann@google.com,
kirill.shutemov@linux.intel.com, vbabka@suse.cz,
dan.j.williams@intel.com, hannes@cmpxchg.org,
iamjoonsoo.kim@lge.com, luto@kernel.org, tj@kernel.org,
vdavydov.dev@gmail.com, ebiederm@xmission.com,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
Date: Wed, 12 Oct 2016 10:15:50 -0700 [thread overview]
Message-ID: <57FE6FC6.70205@linux.intel.com> (raw)
In-Reply-To: <1476229810-26570-1-git-send-email-kandoiruchi@google.com>
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 space. This problem is especially bad for systems like
> Android that use dma-buf fds to share graphics and multimedia buffers between
> processes: these allocations are often large, have complex sharing patterns,
> and are rarely mapped into every process that holds a reference to them.
What do you end up _doing_ with all this new information that you have
here? You know which processes have "pinned" these shared buffers, and
exported that information in /proc. But, then what?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Ruchi Kandoi <kandoiruchi@google.com>,
gregkh@linuxfoundation.org, arve@android.com,
riandrews@android.com, sumit.semwal@linaro.org, arnd@arndb.de,
labbott@redhat.com, viro@zeniv.linux.org.uk,
jlayton@poochiereds.net, bfields@fieldses.org, mingo@redhat.com,
peterz@infradead.org, akpm@linux-foundation.org,
keescook@chromium.org, mhocko@suse.com, oleg@redhat.com,
john.stultz@linaro.org, mguzik@redhat.com, jdanis@google.com,
adobriyan@gmail.com, ghackmann@google.com,
kirill.shutemov@linux.intel.com, vbabka@suse.cz,
dan.j.williams@intel.com, hannes@cmpxchg.org,
iamjoonsoo.kim@lge.com, luto@kernel.org, tj@kernel.org,
vdavydov.dev@gmail.com, ebiederm@xmission.com,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
Date: Wed, 12 Oct 2016 10:15:50 -0700 [thread overview]
Message-ID: <57FE6FC6.70205@linux.intel.com> (raw)
In-Reply-To: <1476229810-26570-1-git-send-email-kandoiruchi@google.com>
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 space. This problem is especially bad for systems like
> Android that use dma-buf fds to share graphics and multimedia buffers between
> processes: these allocations are often large, have complex sharing patterns,
> and are rarely mapped into every process that holds a reference to them.
What do you end up _doing_ with all this new information that you have
here? You know which processes have "pinned" these shared buffers, and
exported that information in /proc. But, then what?
next prev parent reply other threads:[~2016-10-12 17:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 23:50 [RFC 0/6] Module for tracking/accounting shared memory buffers Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 1/6] fs: add installed and uninstalled file_operations Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 2/6] drivers: misc: add memtrack Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 3/6] dma-buf: add memtrack support Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 4/6] memtrack: Adds the accounting to keep track of all mmaped/unmapped pages Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 5/6] memtrack: Add memtrack accounting for forked processes Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-12 3:29 ` Hillf Danton
2016-10-12 3:29 ` Hillf Danton
2016-10-12 3:29 ` Hillf Danton
2016-10-12 3:29 ` Hillf Danton
2016-10-12 0:26 ` [RFC 0/6] Module for tracking/accounting shared memory buffers Al Viro
2016-10-12 0:26 ` Al Viro
2016-10-12 1:14 ` Rob Clark
2016-10-12 1:14 ` Rob Clark
2016-10-12 1:14 ` Rob Clark
2016-10-12 9:09 ` Christian König
2016-10-12 9:09 ` Christian König
2016-10-12 9:09 ` Christian König
2016-10-12 9:09 ` Christian König
2016-10-12 17:15 ` Dave Hansen [this message]
2016-10-12 17:15 ` Dave Hansen
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=57FE6FC6.70205@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arve@android.com \
--cc=bfields@fieldses.org \
--cc=dan.j.williams@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ebiederm@xmission.com \
--cc=ghackmann@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jdanis@google.com \
--cc=jlayton@poochiereds.net \
--cc=john.stultz@linaro.org \
--cc=kandoiruchi@google.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=labbott@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mguzik@redhat.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=riandrews@android.com \
--cc=sumit.semwal@linaro.org \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=vdavydov.dev@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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.