Received: by 10.223.176.46 with SMTP id f43csp971580wra; Fri, 26 Jan 2018 09:42:29 -0800 (PST) X-Google-Smtp-Source: AH8x227XqVObFjUNacp/4+a7+RR2lClf0afMWfGHmDSdPRzPT+GTZwQLHFBWHoJYoMiQ1JpNtEhI X-Received: by 10.98.178.17 with SMTP id x17mr19928129pfe.57.1516988549753; Fri, 26 Jan 2018 09:42:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516988549; cv=none; d=google.com; s=arc-20160816; b=mZlHy4JoyhFvaiZ1YaHWJ9oNX4bC+CeYFzpPAJoF3grU6UPOGUOevGB+4CA2z4qm1g XR639VQpO4DnZpjjKMNKT7jhE6ljS0KFg0nJBrt+qC/ISBN3UhW8fv+gW6HDPYfWXFam 2rlB91SfrlSKzUzF/NeQyHUc0SzhWRtPfUrIA2nkKjKDPOwOxwsiqeu6xzfOXcg+9GU6 lpi5DJOSoULcUvwvwVA5Hj1Dw5VPP84FMIgyZqLD3aKMRUfBS1M4XifJIBTzKIv2MYLP unz+zotWdaLZ/vsKS+33rHGizxUco1jViiG6AX/3GBEe6iG3yrX2o9mhF18BpClzCkVm baDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=d40ssERIVN2O+X4B/Wa5sz6qeCf6mSYksJiCZHFi51M=; b=WAaiV31EHN+7Xb9hSHVBOXWACVb2L4CAA6FiKz/6CR4zDAa+GqElEoptL+D2lzgWhg aM6MPu5wQEIqnvrdOa1JJ4WHEfxLOidtYkwfBLbq6/2GH/OJ4adTqgQ7TaJzamAu8vCv 3OJ6m4O8KZnaJh/lDRgqCF2T8TGoYigtN+WlSmZR+WSM+rKGmII8OE81lRbWe5+GQ4UY hs88s/hGyeKBzSdyJ0U9GNjs79pt/mktPCnDJqcN7D/VhubnlIrFzit8GX8HVLfPqdFT PkW13TP3oC4CHX/tQYTMZGYxp7Wy7+fCRyYffpy5Y8H7yjhXofpV7rRX/w2AMGcbwzIN xksQ== 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 15si961633pfa.303.2018.01.26.09.42.15; Fri, 26 Jan 2018 09:42:29 -0800 (PST) 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 S1751734AbeAZRlv (ORCPT + 99 others); Fri, 26 Jan 2018 12:41:51 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:51514 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbeAZRlu (ORCPT ); Fri, 26 Jan 2018 12:41:50 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 739371596; Fri, 26 Jan 2018 09:41:49 -0800 (PST) Received: from armageddon.cambridge.arm.com (armageddon.cambridge.arm.com [10.1.206.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1C51C3F318; Fri, 26 Jan 2018 09:41:47 -0800 (PST) Date: Fri, 26 Jan 2018 17:41:45 +0000 From: Catalin Marinas To: Marek Szyprowski Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Bartlomiej Zolnierkiewicz , Will Deacon , Inki Dae , Russell King Subject: Re: [RFC 2/2] arm64: compat: cacheflush syscall: process only pages that are in the memory Message-ID: <20180126174145.6gtfjjoxb57d7qwt@armageddon.cambridge.arm.com> References: <20180126111441.29353-1-m.szyprowski@samsung.com> <20180126111441.29353-2-m.szyprowski@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180126111441.29353-2-m.szyprowski@samsung.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 26, 2018 at 12:14:41PM +0100, Marek Szyprowski wrote: > @@ -32,23 +33,36 @@ > static long > __do_compat_cache_op(unsigned long start, unsigned long end) [...] > + if (follow_page(vma, start, 0)) { > + ret = __flush_cache_user_range(start, start + chunk); > + if (ret) > + goto done; > + } This looks pretty expensive for pages already in memory. Could we do some tricks with the AT instruction in __flush_cache_user_range() so that we skip the flushing if the page isn't there? We know that when a page is mapped, the cache will get cleaned/invalidated via set_pte_at() + sync_icache_dcache(), so the only problem of a race is flushing the caches twice for a page. If a page gets unmapped after AT, we may bring it back through the cache ops. -- Catalin