On 2023/7/28 16:42, Laurent Pinchart wrote:
On Fri, Jul 28, 2023 at 05:28:56PM +0900, Tomasz Figa wrote:
On Fri, Jul 28, 2023 at 5:18 PM Laurent Pinchart wrote:
On Fri, Jul 28, 2023 at 01:33:47PM +0900, Sergey Senozhatsky wrote:
On (23/07/27 17:17), Tomasz Figa wrote:
On Fri, Jun 30, 2023 at 7:47 PM Hsia-Jun Li wrote:
Hello All
This RFC tries to address the following problems:
1. Application may request too many buffers, increasing pressure to
system's memory allocator(Thinking about running Android with 8K UHD
playback in a system with only 2 GiB memory available);
Yeah, I think that's something that has to be addressed. It was also
mentioned recently in the review of the DELETE_BUF series. I think we
need some kind of accounting of the allocations to the processes, so
that the per-process limits of memory usage could apply. Let me add
+Sergey Senozhatsky who often crosses his path with kernel memory
management.
That's an interesting topic. The usual approach would be memcg: we
create a memory controller, set memory usage limit, then move tasks
under that controller. The last part is problematic, as it implies
a well-behaving user-space. I'm not aware of a simple way (or any
way for that matter) to "automatically enforce" memcg on a process
group.
From what I can tell networking code attempts to "enforce" memcg on its
allocations, and hence has to manually charge memcg. For instance, take
a look at sock_reserve_memory() and corresponding mem_cgroup_charge_skmem()
call.
So I wonder if we can take a closer look at what networking does and
do something similar in vb2.
It's a long-standing issue that would be nice to solve indeed. I however
wonder if we should do so in vb2, or instead invest our time and efforts
in transitioning to DMA heaps and solving the memory accounting issue
there.
Would we then provide some way to disable MMAP buffer support for
applications? Or you're thinking more about backing MMAP allocations
with DMA-buf heaps internally in the kernel?
Long term I'd like to see MMAP going away, replaced with DMA heaps.
That's veeeery long term though. In the meantime, maybe an option to
disable MMAP support (either a compilation option or a kernel command
line option) would be useful.
MMAP is a confusion name, it means the driver would allocate memory in
the device's memory space,
which turns out to be the unified memory(system memory) in the most
embedded platform.
While we can't disable such option even for those embedded platform, a
few cache hints are missing in DMA-heap.
For example, the page contiguous requirement hints(Device's iommu only
support large page size).
