Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp819831imm; Wed, 25 Jul 2018 06:48:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfKQkh1xTl7R4T3qsOYtE7xQkIu3YUA+kZQQhORx2fpeX2TRgcSGcf2NRSsbx67HUapsy8B X-Received: by 2002:a17:902:b40c:: with SMTP id x12-v6mr21500907plr.163.1532526525808; Wed, 25 Jul 2018 06:48:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532526525; cv=none; d=google.com; s=arc-20160816; b=bgK7a4r2nnidYAF2xBhOVBN8lWCI1ArztGfCOqBann6OKqkb03vah2eT3AWbVV8rdQ ojWuKaTIySLucgg5RACZhqFaXB1jbbZbX0lw6tH41m2HAveCQVF8d9nESOSmN6FfEZvv 4H99p3D5W7j3nG3Zvzr2kzbgbCzORNvJrMWUGqfP8NXY8tI2EbfTrIDsDL9Ktx6JOO8L cWPbvtLubvwwIwuC+hK97Smukuyue0nWyGtpqUzuvGvC3SbvrYqxXUUbgcNO/zAoqnPx j0o4vkxY+5gEfmgF2RZwG1tbqBMBPN6NBFss+bCz5szTlSLtNwim+T/MDsSsc1/EfxXo ZBqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=rlRgA2HAAItKHMV4Sp4q9L0nNx7KkyVsqEWQx1KRZso=; b=mpGltRpkuAsZaAliAKWHS/otMa4wOqx3A0ttT8d+AFFFQBVS7xTYjF2RQhYry3CTn+ vGEkPp2RW19+ZEFpDzgQIq+6f/UkOJqutbfi/ptXMMdOYjBgOJm2R9jGkGnQexuiozX8 cMtDSZwhBermhP/gwiDVPHosmfsLEi4DkUOqE9EU7U1+T/nK/R2sbsp/gwgnYP5X9a88 MwQzbn7hEPPeE3+S3sP/CAmk2WjqHK7l3GeK59iXeCok1NWtf5mjvsGM4mDSeuajpeip gTb8MtchzhJWT9wPd0J+oSRwUeaPFJXL1d/OOY6QFFAftBRrwMS4KXRuC10Pnicj/gtm en1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=SbsWsOHe; 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 r192-v6si4420626pgr.17.2018.07.25.06.48.30; Wed, 25 Jul 2018 06:48:45 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=SbsWsOHe; 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 S1729119AbeGYO6s (ORCPT + 99 others); Wed, 25 Jul 2018 10:58:48 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:38664 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728496AbeGYO6r (ORCPT ); Wed, 25 Jul 2018 10:58:47 -0400 Received: by mail-oi0-f65.google.com with SMTP id v8-v6so13966054oie.5; Wed, 25 Jul 2018 06:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rlRgA2HAAItKHMV4Sp4q9L0nNx7KkyVsqEWQx1KRZso=; b=SbsWsOHeliEGtParIs4plZ6F3R+NPeC7kgUMoDb15XBbhlYvCmoFM3oDh0f59mYP3L T52Ruwd7G5kTeorOH/lpjiOaXsBGWrQ+hBzAreYEOnCMzO0G3hhlCc8aBAqDCh93HvpS 3Wtx74ZCXMwTkO5PsAUxZENxwixpCLWCTxWidWocM5m8ojxqtEDxroTvK9mqTjQUZcBC 43EqZQTquyQxhHmv5RGTP1dgDT622cXUBI4znesxUHgFFM4oeIyZOprlkxm7stbO4FcC ckEOuN3Y1VE4lKGlTlW4d3ZY4g4SDSwJ2l8MoXfLlKkJ8bYUtEc+K6fYo5HwSeFopuwU S5cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rlRgA2HAAItKHMV4Sp4q9L0nNx7KkyVsqEWQx1KRZso=; b=Cvj+yExXxLCIJbRKijAIqGWY22EXuxb2JqmFUlB9zchvBLsQX5QNsMWUXEohZ0tZ8b mge4BbpGXM2Jqjtkqa7rbFEbCMgJ+zmZWzBhRCKIMaaqmzFaD8bLP3rz36FWQXILXq/m 7/GUywLXQE7/4FFmXkm3EVdg1U/DASEO9XUK/BijDFI5Y4Q2cF5wwNDM5tYP9LPh8VmH js6Ry64W4UJ+6NTJnTpvlr6OXkOx/TPdowpp3m/l9r4nTOthIvca1ecXKkpSuw2CPKXB FQHryHzB34VJUFFNzAtk2EWBACPUyDJB8OHUIgS/rR0KxWFujBWt9C1P/vKbFr2IL4iP pdLw== X-Gm-Message-State: AOUpUlEwfwRR+6wxBKEqUVmjXQjE/mb3BLrPetW5PQKDIDfb97DQze7R IAhl9zfRBw+kNkMcgsIr00Pn8Bh4JBuf9yAPpUZRJZKo X-Received: by 2002:aca:dec6:: with SMTP id v189-v6mr3593322oig.98.1532526421556; Wed, 25 Jul 2018 06:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:734:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 06:46:41 -0700 (PDT) In-Reply-To: References: From: "Matwey V. Kornilov" Date: Wed, 25 Jul 2018 16:46:41 +0300 X-Google-Sender-Auth: oCCfMCKZjliHDF_3-YDSk64rACY Message-ID: Subject: Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer To: Alan Stern Cc: Tomasz Figa , Ezequiel Garcia , Hans de Goede , Hans Verkuil , Mauro Carvalho Chehab , Laurent Pinchart , Steven Rostedt , mingo@redhat.com, Mike Isely , Bhumika Goyal , Colin King , Linux Media Mailing List , Linux Kernel Mailing List , Kieran Bingham , keiichiw@chromium.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-07-24 23:55 GMT+03:00 Alan Stern : > On Tue, 24 Jul 2018, Matwey V. Kornilov wrote: > >> 2018-07-23 21:57 GMT+03:00 Alan Stern : >> > On Mon, 23 Jul 2018, Matwey V. Kornilov wrote: >> > >> >> I've tried to strategies: >> >> >> >> 1) Use dma_unmap and dma_map inside the handler (I suppose this is >> >> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP) >> > >> > Yes. >> > >> >> 2) Use sync_cpu and sync_device inside the handler (and dma_map only >> >> once at memory allocation) >> >> >> >> It is interesting that dma_unmap/dma_map pair leads to the lower >> >> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform. >> >> At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the >> >> handler, and sync_cpu/sync_device - ~65 usec. >> >> >> >> However, I am not sure is it mandatory to call >> >> dma_sync_single_for_device for FROM_DEVICE direction? >> > >> > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write >> > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is >> > not needed. >> >> Well, I measured the following at armv7l. The handler execution time >> (URB_NO_TRANSFER_DMA_MAP is used for all cases): >> >> 1) coherent DMA: ~3000 usec (pwc is not functional) >> 2) explicit dma_unmap and dma_map in the handler: ~52 usec >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~56 usec >> >> So, I suppose that unfortunately Tomasz suggestion doesn't work. There >> is no performance improvement when dma_sync_single is used. >> >> At x86_64 the following happens: >> >> 1) coherent DMA: ~2 usec >> 2) explicit dma_unmap and dma_map in the handler: ~3.5 usec >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~4 usec >> >> So, whats to do next? Personally, I think that DMA streaming API >> introduces not so great overhead. >> Does anybody happy with turning to streaming DMA or I'll introduce >> module-level switch as Ezequiel suggested? > > How about using the dma_unmap and dma_map calls in the USB core? If > they add the same overhead as putting them in the handler, I think it > would be acceptable for x86_64. Sure, that is the simplest way to implement streaming API. > > It certainly is odd that the dma_sync_single APIs take longer than > simply mapping and unmapping. Well. I am surprised too. Probably, it is related to that only 9560 bytes are used for each URB. It is only three memory pages. > > Alan Stern > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382