Re: [RFC]: m2m dec reports the graphics memory requirement

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

-- 
Regards,

Laurent Pinchart