From: Michal Hocko <mhocko@suse.com>
To: Jaewon Kim <jaewon31.kim@samsung.com>
Cc: "T.J. Mercier" <tjmercier@google.com>,
"jstultz@google.com" <jstultz@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>
Subject: Re: [PATCH v3] dma-buf/heaps: system_heap: avoid too much allocation
Date: Thu, 13 Apr 2023 08:55:15 +0200 [thread overview]
Message-ID: <ZDenU98chAfH9jSj@dhcp22.suse.cz> (raw)
In-Reply-To: <20230413001658epcms1p611d149fcbbbd06fc17387724f4f16359@epcms1p6>
On Thu 13-04-23 09:16:58, Jaewon Kim wrote:
> >On Wed, Apr 12, 2023 at 4:38?AM Jaewon Kim <jaewon31.kim@samsung.com> wrote:
> >
> >> Yes I think you're right. As a allocator, dma-buf system heap looks to be loose
> >> in memory allocation. Limiting dmabuf memory may be required. But I think there
> >> is no nice and reasonable way so far. And the dma-buf system heap is being
> >> widely used in Android mobile system. AFAIK the camera consumes huge memory
> >> through this dma-buf system heap. I actually even looked a huge size request
> >> over 2GB in one dma-buf request.
> >>
> >Hey can you point me to where you saw a request that big? That's a
> >non-buggy request?!
>
> (let me resend as plain text)
> It was one of camera scenarios. I internally asked and heard that was not a bug
> but normal. I think 2GB looks too big for one graphics buffer but it could be
> for other purposes like camera. I think the system heap should support that.
Is that any of the upstream drivers or something sitting out of the
tree.
> Regarding __GFP_RETRY_MAYFAIL, we may need to say dma-buf system heap was
> designed to gather many pages up to a requested size. If mm returns NULL due to
> __GFP_RETRY_MAYFAIL, dma-buf system heap will release other already allocated
> pages, so that it may help to avoid oom.
This really depends on the other activity on the system. If you have a
more concurrent memory demand at the time then you might be just out of
the luck. Really, claiming huge portion of the memory shouldn't be done
nilly willy.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2023-04-13 6:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230410073304epcas1p4cf3079b096994d69472b7801bd530bc7@epcas1p4.samsung.com>
2023-04-10 7:32 ` [PATCH v3] dma-buf/heaps: system_heap: avoid too much allocation Jaewon Kim
2023-04-12 8:22 ` Michal Hocko
2023-04-12 8:57 ` Jaewon Kim
2023-04-12 9:23 ` Michal Hocko
2023-04-12 9:44 ` Jaewon Kim
2023-04-12 11:02 ` Michal Hocko
2023-04-12 11:37 ` Jaewon Kim
2023-04-12 11:51 ` Michal Hocko
2023-04-12 12:35 ` Jaewon Kim
2023-04-12 13:01 ` Michal Hocko
2023-04-12 16:49 ` T.J. Mercier
2023-04-12 22:10 ` Jaewon Kim
2023-04-13 0:16 ` Jaewon Kim
2023-04-13 6:55 ` Michal Hocko [this message]
2023-04-13 7:01 ` Jaewon Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZDenU98chAfH9jSj@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.vetter@ffwll.ch \
--cc=hannes@cmpxchg.org \
--cc=jaewon31.kim@gmail.com \
--cc=jaewon31.kim@samsung.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.