Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Mime-Version: 1.0
Subject: RE: [PATCH v3] dma-buf/heaps: system_heap: avoid too much
 allocation
Reply-To: jaewon31.kim@samsung.com
Sender: Jaewon Kim <jaewon31.kim@samsung.com>
From:   Jaewon Kim <jaewon31.kim@samsung.com>
To:     Michal Hocko <mhocko@suse.com>
CC:     "jstultz@google.com" <jstultz@google.com>,
        "tjmercier@google.com" <tjmercier@google.com>,
        "sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
        "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "hannes@cmpxchg.org" <hannes@cmpxchg.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "jaewon31.kim@gmail.com" <jaewon31.kim@gmail.com>
In-Reply-To: <ZDabMEUFE2N3dvxZ@dhcp22.suse.cz>
Message-ID: <20230412123532epcms1p23092e51df04b3fb4e18e90b324ebcaa4@epcms1p2>
Date:   Wed, 12 Apr 2023 21:35:32 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 101P
DLP-Filter: Pass
References: <ZDabMEUFE2N3dvxZ@dhcp22.suse.cz>
        <ZDaP4/PYyb9tKGQi@dhcp22.suse.cz> <ZDZ4j7UdBt32j28J@dhcp22.suse.cz>
        <ZDZqYTSHBNGLq0zI@dhcp22.suse.cz>
        <20230410073228.23043-1-jaewon31.kim@samsung.com>
        <20230412085726epcms1p7d2bec2526e47bd10a3b6ea6a113c9cc3@epcms1p7>
        <20230412094440epcms1p445319579ead0d0576bb616ebb07501b4@epcms1p4>
        <20230412113759epcms1p8cb15b54e3a96c7616419cb030d16f804@epcms1p8>
        <CGME20230410073304epcas1p4cf3079b096994d69472b7801bd530bc7@epcms1p2>
Precedence: bulk

>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,
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.

IMO if possible mm should be able to track the dma-buf size as stat in
mm_rss_stat for each process. Then oomk is able to know size through
get_mm_rss. Actually in mobile device environment, there is one more
this kind of allocator. That is graphics drivers. They also consumes
quite much memory and they may allocate as userspace wants.

Jaewon Kim