All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	keiichiw@chromium.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Douglas Anderson <dianders@chromium.org>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	"Matwey V. Kornilov" <matwey@sai.msu.ru>
Subject: Re: [RFC PATCH v1] media: uvcvideo: Cache URB header data before processing
Date: Thu, 09 Aug 2018 01:33:40 +0300	[thread overview]
Message-ID: <2414943.eZ5QIXTjLV@avalon> (raw)
In-Reply-To: <CAAFQd5AFSFKeMhdpW5PusrtcvD1f9DSu7_MQQyy6fB=HbHvVLw@mail.gmail.com>

Hi Tomasz,

On Wednesday, 8 August 2018 19:27:42 EEST Tomasz Figa wrote:
> On Thu, Aug 9, 2018 at 1:21 AM Laurent Pinchart wrote:
> > On Wednesday, 8 August 2018 17:20:21 EEST Alan Stern wrote:
> >> On Wed, 8 Aug 2018, Keiichi Watanabe wrote:
> >>> Hi Laurent, Kieran, Tomasz,
> >>> 
> >>> Thank you for reviews and suggestions.
> >>> I want to do additional measurements for improving the performance.
> >>> 
> >>> Let me clarify my understanding:
> >>> Currently, if the platform doesn't support coherent-DMA (e.g. ARM),
> >>> urb_buffer is allocated by usb_alloc_coherent with
> >>> URB_NO_TRANSFER_DMA_MAP flag instead of using kmalloc.
> >> 
> >> Not exactly.  You are mixing up allocation with mapping.  The speed of
> >> the allocation doesn't matter; all that matters is whether the memory
> >> is cached and when it gets mapped/unmapped.
> >> 
> >>> This is because we want to avoid frequent DMA mappings, which are
> >>> generally expensive. However, memories allocated in this way are not
> >>> cached.
> >>> 
> >>> So, we wonder if using usb_alloc_coherent is really fast.
> >>> In other words, we want to know which is better:
> >>> "No DMA mapping/Uncached memory" v.s. "Frequent DMA mapping/Cached
> >>> memory".
> > 
> > The second option should also be split in two:
> > 
> > - cached memory with DMA mapping/unmapping around each transfer
> > - cached memory with DMA mapping/unmapping at allocation/free time, and
> > DMA sync around each transfer
> > 
> > The second option should in theory lead to at least slightly better
> > performances, but tests with the pwc driver have reported contradictory
> > results. I'd like to know whether that's also the case with the uvcvideo
> > driver, and if so, why.
> 
> I thought that the results from retesting on pwc, after making sure
> that cpu frequency stays the same all the time, actually clarified
> this and indeed map once, sync repeatedly was the fastest?

I had missed that, thank you for the information. I've now caught up with the 
pwc thread.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2018-08-09  0:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27 10:34 [RFC PATCH v1] media: uvcvideo: Cache URB header data before processing Keiichi Watanabe
2018-06-27 17:21 ` Kieran Bingham
2018-07-24  4:18   ` Keiichi Watanabe
2018-07-24 11:07     ` Kieran Bingham
2018-07-24 11:03 ` Kieran Bingham
2018-07-30 16:00 ` Laurent Pinchart
2018-07-30 16:03   ` Kieran Bingham
2018-07-30 16:03     ` Kieran Bingham
2018-08-08  4:08   ` Tomasz Figa
2018-08-08  8:42     ` Laurent Pinchart
2018-08-08 12:45       ` Keiichi Watanabe
2018-08-08 13:07         ` Kieran Bingham
2018-08-08 14:02           ` Keiichi Watanabe
2018-08-08 14:20         ` Alan Stern
2018-08-08 16:22           ` Laurent Pinchart
2018-08-08 16:27             ` Tomasz Figa
2018-08-08 22:33               ` Laurent Pinchart [this message]
2018-08-08 16:29             ` Ezequiel Garcia
2018-08-08 22:35               ` Laurent Pinchart
2018-08-08 17:04             ` Alan Stern
2018-08-08 22:20               ` Laurent Pinchart
2018-08-09 14:12                 ` Alan Stern
2018-08-24  6:06                   ` Keiichi Watanabe
2018-08-24 22:00                     ` Kieran Bingham

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=2414943.eZ5QIXTjLV@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dianders@chromium.org \
    --cc=ezequiel@collabora.com \
    --cc=keiichiw@chromium.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=matwey@sai.msu.ru \
    --cc=mchehab@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tfiga@chromium.org \
    /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.