On Wed 12-04-23 21:35:32, Jaewon Kim wrote: > >On Wed 12-04-23 20:37:59, Jaewon Kim wrote: > >> Limiting dmabuf memory may be required. But I think there > >> is no nice and reasonable way so far. > > > >If that is really the way then the patch doesn't really add a big > >benefit. It doesn't really prevent OOMs (or panics due to OOM) as the > >allocator still allows to consume arbitrary amount of memory. The > >provided check is not able to tell between buggy and legit calls. > >-- > >Michal Hocko > >SUSE Labs > > Yes it could be. Though the buggy call is blocked by totalram_pages check, It seems our definitions of buggy differ here. I do not see much difference between totalram_pages +- PAGE_SIZE (or any epsilon for that matter). Both would put the system down to its knees without a way out other than panic. > mm may suffer memory shortage due to the huge memory consumption through > dma-buf system heap. We just hope Android LMKD or oomk kills the memory > hoggers prior to oom panic. You seem to be missing an important point. If the global OOM killer is not able to find a victim the LMKD or oomk are highly unlikely as well (unless they ignore OOM_SCORE_ADJ_MIN). > IMO if possible mm should be able to track the dma-buf size as stat in > mm_rss_stat for each process. I do remember some proposals from the past and IIRC the main problem was how to attribute those buffers to the actual owner. I believe I have give you some arguments to consider. The rest is up to you. As I've said I do not have any stakes in dmabuf. The patch itself is not actively harmful, it is just adding an illusion of a fix while it doesn't give much. -- Michal Hocko SUSE Labs
