Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4773898imm; Mon, 30 Jul 2018 23:08:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcGr5OzSyW02WTHkXyJ4jqCBGytZ1gnOycH2n/YGYZclTBjEKozt+4IG4wPPk9eFHVm4GQ1 X-Received: by 2002:a63:704f:: with SMTP id a15-v6mr19150874pgn.443.1533017292805; Mon, 30 Jul 2018 23:08:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533017292; cv=none; d=google.com; s=arc-20160816; b=u7d6WZ9nlVlnKLHaCq4SNxYTXZlms/ZNTChDFOTRl8P4FFKNvuBn6zsUYYQOctQfkd aH61QGnKZ+M/tJR7XeTySP5iEsfV+T+eyUEf6vqwEHzBEYBMwbc39tftuqWL892styz3 2wvjAwA19tdkvFRUVwcmy9UZ2Z+iNBMr1ebgNlSNxnN77gT2Vp5cn/3GhQAwCgTvBiBC GYIuFgiLLiZoGGFcUWQvTdOJJmpNbFV5lW+BeK7SjT+0FROnPeDTxGNyHAkEgDYKeiB4 8etKVEBGW9fDBKu7hP1KYi6fuJaI9LGYTM0RKsI5Q2lJLGacBzNGAvkQi/tMvtKGm3W/ nJ3A== 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 :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=e5caXUogE0rfXz6bwSVzTjVit3uhCHDvkJZvyD1/m7M=; b=acMF4XGjEEtJvrSh688L+ZkkhihWAa/0DTTrA9WoQ3ScrS6/2X1sEX5B+/QsNC3sBS jS0G9EUJtHrq5hVjfW1w29soLnBl6KY2hrgnT61g1ysy7tpjDQFpWzxS03nX0Ohk0sG9 9SZwsjo5WFTS7KkEC9HK+QtF1anj4RYAIy80W8imPD3AEA+ixIsAhFoDJ/1B4Jq62Hu7 qd8TUtiWX6eKuKFZxxCazogCM6X33xrmqV1OU/Ua+2i1GvZbrqG8UaipQXQiwI+Hbcwq jQdzVYB0y1K04JdHCc3wp139MMDlYEy7gdSFy/Tas6nHCVGCv5j4Uk/EuOGAA8d3WSsQ lV9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=j4BVfX+n; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 73-v6si12272311pgh.343.2018.07.30.23.07.58; Mon, 30 Jul 2018 23:08:12 -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=pass header.i=@chromium.org header.s=google header.b=j4BVfX+n; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729643AbeGaHpe (ORCPT + 99 others); Tue, 31 Jul 2018 03:45:34 -0400 Received: from mail-yb0-f195.google.com ([209.85.213.195]:42569 "EHLO mail-yb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726824AbeGaHpd (ORCPT ); Tue, 31 Jul 2018 03:45:33 -0400 Received: by mail-yb0-f195.google.com with SMTP id c10-v6so5716945ybf.9 for ; Mon, 30 Jul 2018 23:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e5caXUogE0rfXz6bwSVzTjVit3uhCHDvkJZvyD1/m7M=; b=j4BVfX+nwa6N73KBg1YAiZfOyWojL23a4xTgaiRmUsMNn75WAsFIIXhQv1W4j1PNsm UqHB9mC2yj8xDqXyeaoTT5/swidkFT3va5ig/WsN2xo053ZjLeyeNa3bLcJmYgyVcx2n qumlYtr92Ws4pUDzCDo0Ktss7LIDnB6Ixkd5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e5caXUogE0rfXz6bwSVzTjVit3uhCHDvkJZvyD1/m7M=; b=eU6HDDiNae66oW3zgHhEFlbVJZQADlxgr+kL8AtIELhh6e/vFUnexbm/nLT89hMCvn 5mbliMdfsc60bBliSNfn41CITio1SSnA8CvqDUPAaJ03La6nECgtD52ahAK6Kgd+eNLK u+mh0e4b+0EavbYkoYVDATCu8AyCuwcwI/Xxl4PAKi34wvs/WvHaoBpHWw8zWohvR69Q XTcrHCt8x/zK0itPe4QrwZQeNA/y9RGFcBnnWPZFsNcJEnKvAc2IcKTJNt904wYcWcZn i4GpBczvlqx/pTvRnaOVGYmMnuOFoYKjl3/h60V1UeJKRndecfZwG6Z7zsO2/PjXjEvP +bXQ== X-Gm-Message-State: AOUpUlF6FcFZA/H1jbBdA0iiZgLdAPra0fqZOAynDn+aHrF4ngK5O6id t9UoUFo8+hez6x+AsrxM1+FXtvD2EtI= X-Received: by 2002:a25:aea5:: with SMTP id b37-v6mr10631644ybj.303.1533017217116; Mon, 30 Jul 2018 23:06:57 -0700 (PDT) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com. [209.85.161.180]) by smtp.gmail.com with ESMTPSA id w143-v6sm21865975yww.49.2018.07.30.23.06.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 23:06:56 -0700 (PDT) Received: by mail-yw0-f180.google.com with SMTP id c135-v6so5338192ywa.0 for ; Mon, 30 Jul 2018 23:06:56 -0700 (PDT) X-Received: by 2002:a0d:dcc3:: with SMTP id f186-v6mr10001707ywe.66.1533017216195; Mon, 30 Jul 2018 23:06:56 -0700 (PDT) MIME-Version: 1.0 References: <20180617143625.32133-1-matwey@sai.msu.ru> <20180617143625.32133-2-matwey@sai.msu.ru> <20180730130702.27664d15@coco.lan> In-Reply-To: <20180730130702.27664d15@coco.lan> From: Tomasz Figa Date: Tue, 31 Jul 2018 15:06:45 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer To: Mauro Carvalho Chehab Cc: Ezequiel Garcia , "Matwey V. Kornilov" , Alan Stern , hdegoede@redhat.com, Hans Verkuil , Mauro Carvalho Chehab , Laurent Pinchart , rostedt@goodmis.org, mingo@redhat.com, Mike Isely , Bhumika Goyal , Colin King , Linux Media Mailing List , Linux Kernel Mailing List 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 On Tue, Jul 31, 2018 at 1:07 AM Mauro Carvalho Chehab wrote: > > Em Tue, 17 Jul 2018 17:10:22 -0300 > Ezequiel Garcia escreveu: > > > Yeah, and not setting URB_NO_TRANSFER_DMA_MAP makes the USB core > > create DMA mappings and use the streaming API. Which makes more > > sense in hardware without hardware coherency. > > > > The only thing that bothers me with this patch is that it's not > > really something specific to this driver. If this fix is valid > > for pwc, then it's valid for all the drivers allocating coherent > > memory. > > We're actually doing this change on other drivers: > https://git.linuxtv.org/media_tree.git/commit/?id=d571b592c6206 > > I suspect that the reason why all USB media drivers were using > URB_NO_TRANSFER_DMA_MAP is just because the first media USB driver > upstream used it. > > On that time, I remember I tried once to not use this flag, but there > was something that broke (perhaps I just didn't know enough about the > USB layer - or perhaps some fixes happened at USB core - allowing it > to be used with ISOC transfers). > > Anyway, nowadays, I fail to see a reason why not let the USB core > do the DMA maps. On my tests after this patch, at the boards I tested > (arm and x86), I was unable to see any regressions. I can see one reason: usb_alloc_coherent() would use dma_pool_alloc() with a fallback to dma_alloc_coherent() to do the allocation. I'm not sure what a typical size for an URB buffer is, but I assume that it's definitely more than 1 page. Order >0 allocations with page allocator (and SLAB, which eventually just falls back to page allocator for such large allocations) are generally considered costly. With allocation through DMA API, mechanisms such as CMA or IOMMU can be used (if available), making it much more likely to have the allocation satisfied on heavy load / long uptime systems. Best regards, Tomasz