On Tue, Apr 20, 2021 at 10:45:21AM +0000, Peter.Enderborg@xxxxxxxx wrote: > On 4/20/21 11:41 AM, Mike Rapoport wrote: > > Hello Peter, > > > > On Tue, Apr 20, 2021 at 09:26:00AM +0000, Peter.Enderborg@xxxxxxxx wrote: > >> On 4/20/21 10:58 AM, Daniel Vetter wrote: > >>> On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote: > >>>> This adds a total used dma-buf memory. Details > >>>> can be found in debugfs, however it is not for everyone > >>>> and not always available. dma-buf are indirect allocated by > >>>> userspace. So with this value we can monitor and detect > >>>> userspace applications that have problems. > >>>> > >>>> Signed-off-by: Peter Enderborg <peter.enderborg@xxxxxxxx> > >>> So there have been tons of discussions around how to track dma-buf and > >>> why, and I really need to understand the use-cass here first I think. proc > >>> uapi is as much forever as anything else, and depending what you're doing > >>> this doesn't make any sense at all: > >>> > >>> - on most linux systems dma-buf are only instantiated for shared buffer. > >>> So there this gives you a fairly meaningless number and not anything > >>> reflecting gpu memory usage at all. > >>> > >>> - on Android all buffers are allocated through dma-buf afaik. But there > >>> we've recently had some discussions about how exactly we should track > >>> all this, and the conclusion was that most of this should be solved by > >>> cgroups long term. So if this is for Android, then I don't think adding > >>> random quick stop-gaps to upstream is a good idea (because it's a pretty > >>> long list of patches that have come up on this). > >>> > >>> So what is this for? > >> For the overview. dma-buf today only have debugfs for info. Debugfs > >> is not allowed by google to use in andoid. So this aggregate the information > >> so we can get information on what going on on the system. > > > > Can you send an example debugfs output to see what data are we talking > > about? > > Sure. This is on a idle system. Im not sure why you need it.The problem is partly that debugfs is > not accessable on a commercial device. I wanted to see what kind of information is there, but I didn't think it's that long :) > Dma-buf Objects: > size flags mode count exp_name buf name ino > 00032768 00000002 00080007 00000002 ion-system-1006-allocator-servi dmabuf17728 07400825 dmabuf17728 > Attached Devices: > Total 0 devices attached > > 11083776 00000002 00080007 00000003 ion-system-1006-allocator-servi dmabuf17727 07400824 dmabuf17727 > Attached Devices: > ae00000.qcom,mdss_mdp:qcom,smmu_sde_unsec_cb > Total 1 devices attached > > 00032768 00000002 00080007 00000002 ion-system-1006-allocator-servi dmabuf17726 07400823 dmabuf17726 > Attached Devices: > Total 0 devices attached > > 11083776 00000002 00080007 00000002 ion-system-1006-allocator-servi dmabuf17725 07400822 dmabuf17725 > Attached Devices: > ae00000.qcom,mdss_mdp:qcom,smmu_sde_unsec_cb > Total 1 devices attached ... > Total 654 objects, 744144896 bytes Isn't the size from the first column also available in fdinfo? Is there anything that prevents monitoring those? -- Sincerely yours, Mike.
