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 already
proposed a solution for this quite a while ago, but never pushed on
upstreaming this since it was only done for a special use case.
Instead of keeping track of how much memory a process has bound (which
is very fragile) my solution only added some more debugging info on a
per fd basis (e.g. how much memory is bound to this fd).
This information was then used by the OOM killer (for example) to make a
better decision on which process to reap.
Shouldn't be to hard to expose this through debugfs or maybe a new fcntl
to userspace for debugging.
I haven't looked at the code in detail, but messing with the per process
memory accounting like you did in this proposal is clearly not a good
idea if you ask me.
Regards,
Christian.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
