lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 08 Aug 2018 19:22:16 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Keiichi Watanabe <keiichiw@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        kieran.bingham@...asonboard.com,
        Douglas Anderson <dianders@...omium.org>,
        ezequiel@...labora.com, matwey@....msu.ru
Subject: Re: [RFC PATCH v1] media: uvcvideo: Cache URB header data before processing

Hello,

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.

> There is no need to wonder.  "Frequent DMA mapping/Cached memory" is
> always faster than "No DMA mapping/Uncached memory".

Is it really, doesn't it depend on the CPU access pattern ?

> The only issue is that on some platform (such as x86) but not others,
> there is a third option: "No DMA mapping/Cached memory".  On platforms
> which support it, this is the fastest option.

-- 
Regards,

Laurent Pinchart



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ