Re: [PATCH v3] dma-buf/heaps: system_heap: avoid too much allocation

[Michal Hocko <mhocko@suse.com>]

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