From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754680AbcCWLMU (ORCPT ); Wed, 23 Mar 2016 07:12:20 -0400 Received: from foss.arm.com ([217.140.101.70]:45664 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752986AbcCWLMK (ORCPT ); Wed, 23 Mar 2016 07:12:10 -0400 Date: Wed, 23 Mar 2016 11:11:55 +0000 From: Mark Rutland To: Laura Abbott Cc: Chen Feng , catalin.marinas@arm.com, akpm@linux-foundation.org, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xuyiping@hisilicon.com, suzhuangluan@hisilicon.com, saberlily.xia@hisilicon.com, dan.zhao@hisilicon.com, linux-arm-kernel@lists.infradead.org Subject: Re: Delete flush cache all in arm64 platform. Message-ID: <20160323111155.GB2057@leverpostej> References: <56EFABD3.7060700@hisilicon.com> <20160321100818.GA17326@leverpostej> <56F01A0A.3030208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F01A0A.3030208@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 21, 2016 at 08:58:02AM -0700, Laura Abbott wrote: > On 03/21/2016 03:08 AM, Mark Rutland wrote: > >On Mon, Mar 21, 2016 at 04:07:47PM +0800, Chen Feng wrote: > >>But if we use VA to flush cache to do cache-coherency with other > >>master(eg:gpu) > >> > >>We must iterate over the sg-list to flush by va to pa. > >> > >>In this way, the iterate of sg-list may cost too much time(sg-table to > >>sg-list) if the sglist is too long. Take a look at the > >>ion_pages_sync_for_device in ion. > >> > >>The driver(eg: ION) need to use this interface(flush cache all) to > >>*improve the efficiency*. > >I'm not sure what to suggest regarding improving efficiency. > > > >Is walking the sglist the expensive portion, or is the problem the cost > >of multiple page-size operations (each with their own barriers)? > > Last time I looked at this, it was mostly the multiple page-size operations. We may be able to amortize some of that cost if we had non-synchronised cache maintenance operations for each page, then followed that up with a single final DSB SY. There are several places in arch/arm64/mm/dma-mapping.c (practically every use of for_each_sg) that could potentially benefit. I'm not sure how much that's likely to gain as it will depend heavily on the microarchitecture. Regardless, it looks like that would require ion_pages_sync_for_device and friends to be reworked, as it seems to only hand single pages down to the architecture backend rather than a more complete sglist. Thanks, Mark.