From: Doug Anderson <dianders@chromium.org>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: "Tiffany Lin" <tiffany.lin@mediatek.com>,
"Andrew-CT Chen" <andrew-ct.chen@mediatek.com>,
"Yunfei Dong" <yunfei.dong@mediatek.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Wei-Shun Chang" <weishunc@google.com>,
"Hans Verkuil" <hverkuil-cisco@xs4all.nl>,
"Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
"Rob Herring" <robh@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] media: mediatek: vcodec: Alloc DMA memory with DMA_ATTR_ALLOC_SINGLE_PAGES
Date: Mon, 22 Apr 2024 12:25:43 -0700 [thread overview]
Message-ID: <CAD=FV=XSyLJiTCHYF7UaLersix0zP-q-MybW+nOR3A2WfccQcg@mail.gmail.com> (raw)
In-Reply-To: <022936a6704d08fbed22e7f241810d857eecaeda.camel@collabora.com>
Hi,
On Mon, Apr 22, 2024 at 11:27 AM Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:
>
> Hi,
>
> Le lundi 22 avril 2024 à 10:03 -0700, Douglas Anderson a écrit :
> > As talked about in commit 14d3ae2efeed ("ARM: 8507/1: dma-mapping: Use
> > DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize alloc"), it doesn't
> > really make sense to try to allocate contiguous chunks of memory for
> > video encoding/decoding. Let's switch the Mediatek vcodec driver to
> > pass DMA_ATTR_ALLOC_SINGLE_PAGES and take some of the stress off the
> > memory subsystem.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> > NOTE: I haven't personally done massive amounts of testing with this
> > change, but I originally added the DMA_ATTR_ALLOC_SINGLE_PAGES flag
> > specifically for the video encoding / decoding cases and I know it
> > helped avoid memory problems in the past on other systems. Colleagues
> > of mine have told me that with this change memory problems are harder
> > to reproduce, so it seems like we should consider doing it.
>
> One thing to improve in your patch submission is to avoid abstracting the
> problems. Patch review and pulling is based on a technical rational and very
> rarely on the trust that it helps someone somewhere in some unknown context.
> What kind of memory issues are you facing ? What is the technical advantage of
> using DMA_ATTR_ALLOC_SINGLE_PAGES over the current approach that helps fixing
> the issue? I do expect this to be documented in the commit message itselfé.
Right. The problem here is that I'm not _directly_ facing any problems
here and I also haven't done massive amounts of analysis of the
Mediatek video codec. I know that some of my colleagues have run into
issues on Mediatek devices where the system starts getting
unresponsive when lots of videos are decoded in parallel. That
reminded me of the old problem I debugged in 2015 on Rockchip
platforms and is talked about a bunch in the referenced commit
14d3ae2efeed ("ARM: 8507/1: dma-mapping: Use
DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize alloc") so I wrote up
this patch. The referenced commit contains quite a bit of details
about the problems faced back in 2015.
When I asked, my colleagues said that my patch seemed to help, though
it was more of a qualitative statement than a quantitative one.
I wasn't 100% sure if it was worth sending the patch up at this point,
but logically, I think it makes sense. There aren't great reasons to
hog all the large chunks of memory for video decoding.
-Doug
next prev parent reply other threads:[~2024-04-22 19:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 17:03 [PATCH] media: mediatek: vcodec: Alloc DMA memory with DMA_ATTR_ALLOC_SINGLE_PAGES Douglas Anderson
2024-04-22 18:27 ` Nicolas Dufresne
2024-04-22 19:25 ` Doug Anderson [this message]
2024-04-23 13:47 ` Nicolas Dufresne
2024-04-23 21:52 ` Doug Anderson
2024-04-26 10:20 ` Fei Shao
2024-05-01 18:31 ` Nicolas Dufresne
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='CAD=FV=XSyLJiTCHYF7UaLersix0zP-q-MybW+nOR3A2WfccQcg@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=andrew-ct.chen@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=nfraprado@collabora.com \
--cc=nicolas.dufresne@collabora.com \
--cc=robh@kernel.org \
--cc=tiffany.lin@mediatek.com \
--cc=weishunc@google.com \
--cc=yunfei.dong@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).