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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 28, 2023 at 5:18 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> 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?

Best regards,
Tomasz




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux