Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1397122imm; Wed, 17 Oct 2018 19:53:52 -0700 (PDT) X-Google-Smtp-Source: ACcGV63S99H6vQ9mj54Kkm4au/Xnyyt81etghMw5kD17CsnYRu3zxGH5V4UrCIRDIffwcdomtZvv X-Received: by 2002:a63:7e1c:: with SMTP id z28-v6mr27127731pgc.190.1539831232561; Wed, 17 Oct 2018 19:53:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539831232; cv=none; d=google.com; s=arc-20160816; b=dyuXfpmmpDVsmpHMivyXCXTy9jl0oMyp4ODag98I5Luqz74L2uGJUyzsUBHiEWMuhK s5i/d8yg4DhJpM4s4VrBvMcQfTDIBm0OZA4oBpIaeJEMZQ0YsF2wnxZtBpYOyiZPWXzA TcoGEHm3qZ5XrTOaaPzGnV0PpDf3wDg0Mc5+V4jH9Sfw5nNU/wEKllHViw0Lv/WuZrDP 53NmyiPSEJudAr+O6KtF0xeqOvv4HpEkJTUHVSWOr/ZgXSg4APrmiZMwJ6lyJemTvUmO MAjWKNMM3T+K+sReKzK42krzLVL+a3ew6Gi1y2LYIa36r7ZwVDalViSQQEWT+OR4Y6c4 gs7g== 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; bh=6sy3ZcN/CTmbCkH9L6A1uqhfR+PZHAwRfReEcTJgX9k=; b=W0ggbRsBH30PSI0VvCxeTYilyje19zLbryE+izR4Y6A5RgTS4rfdc2RGzquXo1r9A6 h8nn6oAM8jHl5YEaSxY0zjFKU/2rG1IxhgsBuw2EHQ0Ehrmr0NognNXW+rtRHKqLK/+C /7POPN/jncSO43qp7kffTS3PWPD/Ch0xyekk9/ZU9LoC79Qwhtmp/2gkK9j2ZMzAlB1Z WWrbbENkiHWp59FuzgKSC6ZWFg+04qDfnU3mUtvQXBVMOHpXz57VVGUWuHYDW+KYyta0 fc657ktwZLSgCwMqEKGgoBAJlOTqVT5Lt4B4EeiN+lGQyffNz4NLRKf34WgkvfDZGFGp ydgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hhnYp7Ef; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9-v6si19345843pgn.512.2018.10.17.19.53.36; Wed, 17 Oct 2018 19:53: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; dkim=pass header.i=@linaro.org header.s=google header.b=hhnYp7Ef; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727363AbeJRKvq (ORCPT + 99 others); Thu, 18 Oct 2018 06:51:46 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:34623 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727247AbeJRKvq (ORCPT ); Thu, 18 Oct 2018 06:51:46 -0400 Received: by mail-wr1-f68.google.com with SMTP id l6-v6so31443710wrt.1 for ; Wed, 17 Oct 2018 19:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6sy3ZcN/CTmbCkH9L6A1uqhfR+PZHAwRfReEcTJgX9k=; b=hhnYp7EfU57wtKKwkUFOg3jsJidi7rtc8NMXReWNwQa5CBCsqn2T/9U9h3d84F1r2Y XwDpxLNwfQVF7iJWZxl6e4BqBrQERVNnuvpczttXapl+Qd507TLwt1+MQ10/Fks0KBgx bJfAXfkUaDLtCTykdpdvApAc3ZcPxuLDuUC4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6sy3ZcN/CTmbCkH9L6A1uqhfR+PZHAwRfReEcTJgX9k=; b=RbTaa/YUHDZV0SH9X4hyMoyxaeEurlyTzHUWoIs86esaMWTJoxL4MBMtKGWHk93AA5 tvNf2M3KBQUQxmMyP4k4qH/flycqLBGfMssXAb7sr/YGvpG/uDeOhvlbwtxyjaUCVixk IFlBKyauD9MD+N/4OAZ+UUQoriVoQo7915TYHd8rKHklkoWy8BStonWMKWU8Tb2B222h aSa5E+d8blKJibhNzE5w0IzNtY/eqOfE1rYqQ/vpWO7nh91A0pW2FNIRpRui37YY809A 4AxPDSeDsBZ0g6fOmrjLH/7fvslOcFu+9dKhprhrmNBi1G4WVbAsT41Ddn9GE/1Ufi04 B+QA== X-Gm-Message-State: ABuFfoh9B76tIdssYjKnn+verLtVNS2I0ocW35pKVrpDqDkZ1upjY0pE //7PQGU9FWUtPNLkHWB4pb2sLDMh1RdLxoFhvO6bjg== X-Received: by 2002:adf:a194:: with SMTP id u20-v6mr18606292wru.50.1539831181952; Wed, 17 Oct 2018 19:53:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:b485:0:0:0:0:0 with HTTP; Wed, 17 Oct 2018 19:53:00 -0700 (PDT) In-Reply-To: <7534ca1d-f874-7809-6125-d9fc72f70e39@redhat.com> References: <1539214413-26173-1-git-send-email-john.stultz@linaro.org> <7534ca1d-f874-7809-6125-d9fc72f70e39@redhat.com> From: John Stultz Date: Wed, 17 Oct 2018 19:53:00 -0700 Message-ID: Subject: Re: [PATCH] staging: ion: Rework ion_map_dma_buf() to minimize re-mapping To: Laura Abbott Cc: lkml , Beata Michalska , Matt Szczesiak , Anders Pedersen , John Reitan , Liam Mark , Sumit Semwal , Greg Kroah-Hartman , Todd Kjos , Martijn Coenen , dri-devel 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 Fri, Oct 12, 2018 at 10:51 AM, Laura Abbott wrote: > > I suspect most of the cost of the dma_map/dma_unmap is from the > cache flushing and not the actual mapping operations. If this > is the case, another option might be to figure out how to > incorporate dma_attrs so drivers can use DMA_ATTR_SKIP_CPU_SYNC > to decide when they actually want to sync. So just to confirm on this point, I basically tested the following change (whitespace corrupt, sorry): diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 24cb666..e76b0e2 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -273,8 +273,8 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment, table = a->table; - if (!dma_map_sg(attachment->dev, table->sgl, table->nents, - direction)) + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents, + direction, DMA_ATTR_SKIP_CPU_SYNC)) return ERR_PTR(-ENOMEM); return table; @@ -284,7 +284,7 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table *table, enum dma_data_direction direction) { - dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction); + dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents, direction, DMA_ATTR_SKIP_CPU_SYNC); } static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) And indeed, that performed similarly to the pre 4.12 ION code (and it also had some of the same image caching error garbage we've seen w/ 4.9 era kernels, which my earlier patch didn't have). So yes, it seems having some way to conditionally skip cpu sync would be good. Though I'm not sure what sort of interface to using this you might have in mind? thanks -john