Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp884877imm; Wed, 8 Aug 2018 07:21:53 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzpAi77/xjXVWTpSR4btmzL5tnaacKzWXs/Zyy+52e2ce8E31Jhe1U/jYNeKM6FZLpgiK+N X-Received: by 2002:a63:b02:: with SMTP id 2-v6mr2717515pgl.301.1533738112942; Wed, 08 Aug 2018 07:21:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533738112; cv=none; d=google.com; s=arc-20160816; b=VKIUgpw04UEipQtIR46CRZUu9xMbrlLRJlVvV6Lu+tL26l5lOx3f3ctpq8ypkzfoqV 2AERCMrQhZEXiOSvzgHsPIFTvOHpfPoOg+9JWXkbw7kWbC1EMqE60yIWsHuoe5z53UJY hFkNWfwj3es1wCfq1b88rxx2w5d9MDQzDHYrWxQpZmr76nw1IgfGUk9IIDaFnn9yTIgp jcS/em7prJnNhIkeqqvYnIbdNrxSEYsmiC/9RqvbtQnMzmp+x1HSw415msmF2S4VoEmo 9hvaAsHe+xem1BQclQ2lLHfSIuOuqMjch4mFsYYaMrY7GLGCKjMmCira5b5jkdSWUham pWCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=9mZRbOfFctNgJr8yWx1aAe9xrWQZ1sSMj1YQr/qpVYk=; b=UfXSY/gOhiu5R+JLbKuZXD18fLZJB5NGDLLLUL+0y1acMdslodIA5PGUx3P01RpegT jbS0pUXw15Ltw9qVs6SWXaZKxPlOKAUKVsZjIulhDo7f2C+xqlDhi/6Yu8zjBkkxWyuA y0kK2oc/YGigcQ9rth7EJ05n+SzTvgtp2YnycSsfPAjNW4G/r6jB3ruuBiCCopOZjISF sCKa9IPwKAXln+U2+pn0R1LM2h0BUlbXP9zhXIo7QHM6j3V/EjfQxeplSi9Zi08UztV3 8OBYS3EMvPeoA2Zx4ToTEL3hEWfW392NwQvynyZUKc+J0KFqgnH686BRs5S6mIhrT8zC o0Og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a61-v6si3571688plc.80.2018.08.08.07.21.38; Wed, 08 Aug 2018 07:21:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727458AbeHHQkP (ORCPT + 99 others); Wed, 8 Aug 2018 12:40:15 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:54768 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727109AbeHHQkO (ORCPT ); Wed, 8 Aug 2018 12:40:14 -0400 Received: (qmail 2100 invoked by uid 2102); 8 Aug 2018 10:20:21 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Aug 2018 10:20:21 -0400 Date: Wed, 8 Aug 2018 10:20:21 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Keiichi Watanabe cc: Laurent Pinchart , Tomasz Figa , Linux Kernel Mailing List , Mauro Carvalho Chehab , Linux Media Mailing List , , Douglas Anderson , , Subject: Re: [RFC PATCH v1] media: uvcvideo: Cache URB header data before processing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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". There is no need to wonder. "Frequent DMA mapping/Cached memory" is always faster than "No DMA mapping/Uncached memory". 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. Alan Stern