Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2399643ybi; Thu, 20 Jun 2019 14:32:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqyEoqioGV/mLm6g5d3VcEKcUbn/QRvbCmxAOTZr/U+y0wezw9CSFxzj54gBh7ihdaUL3SHI X-Received: by 2002:a17:902:e208:: with SMTP id ce8mr9343035plb.205.1561066359429; Thu, 20 Jun 2019 14:32:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561066359; cv=none; d=google.com; s=arc-20160816; b=Kv1ZQo/VThUgc+2FEkvNNAqk5olU+SHr0siJ6cLHDmdgGwZTkr+j+o7zzYuaa/lMXE d689KX1uFqaYLpWfXNDSmJggEp0PqlO08yaH1C3OSIUN8I+q30GOt1zgVP70kFs1q7z8 NdLuHr0DQLb9LivrYQSBNZBJJFAA5wM3/exSnupPodmo+W0Fjw3nv5cltFDgUdDzjZOM QRIxjXY9dUkBv4PGucYPDH+eMrHMvl4BqXLggzXe0fQamnuvOdWnW1bzJswW77tnjnux Bj78/EGdsSGX8ZPOhMnv4uyNDmcVVa7EeORuFQt2NdBpY9tzL+e4a7FudAAAnC2blWwg 9vdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=u/4lpOTrasc/MMyF7sEUYw6eNKYx+4DGyx+RyjMFrII=; b=MbAl8bxv1oWlCqBzERsHjRUqMOXgwjmh/nE/7fIJserWaUhyxF45b1XPm2i4uQuBXZ ea2RBuNcSs4U78rnE0MrdGflvqGCRjAidnXk7RHnqH9mZjo+QhiePFIxvUFh1c5xE/1Q kLYczxrVDWh7/RUayjTYaP45TY7kJgqQlT6tm7ueEGfavnfwy2jrcFkhRpbGpd5v8doy pZp+nwWf9lMKn34Bp66xMXkFmiSCb6Rw8nzqsV2N3D59axiQWUHM6TiKXuppgqJxxp74 nSb2DIKJPFQWXVFIAtPb/l2zbN91CUtagO3R33xava5xxrshsf/AOBNuMUKI3kZLI3tL x9aQ== 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 h128si547656pgc.499.2019.06.20.14.32.23; Thu, 20 Jun 2019 14:32:39 -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; 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 S1726505AbfFTVbu (ORCPT + 99 others); Thu, 20 Jun 2019 17:31:50 -0400 Received: from mga02.intel.com ([134.134.136.20]:57486 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725905AbfFTVbu (ORCPT ); Thu, 20 Jun 2019 17:31:50 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2019 14:31:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,398,1557212400"; d="scan'208";a="181950299" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by fmsmga001.fm.intel.com with ESMTP; 20 Jun 2019 14:31:48 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 8001B300FFA; Thu, 20 Jun 2019 14:31:48 -0700 (PDT) From: Andi Kleen To: Dan Williams Cc: Bjorn Helgaas , Nadav Amit , Andrew Morton , LKML , Linux-MM , Borislav Petkov , Toshi Kani , Peter Zijlstra , Dave Hansen , Ingo Molnar , "Kleen\, Andi" Subject: Re: [PATCH 3/3] resource: Introduce resource cache References: <20190613045903.4922-1-namit@vmware.com> <20190613045903.4922-4-namit@vmware.com> <20190617215750.8e46ae846c09cd5c1f22fdf9@linux-foundation.org> <98464609-8F5A-47B9-A64E-2F67809737AD@vmware.com> <8072D878-BBF2-47E4-B4C9-190F379F6221@vmware.com> Date: Thu, 20 Jun 2019 14:31:48 -0700 In-Reply-To: (Dan Williams's message of "Wed, 19 Jun 2019 14:53:54 -0700") Message-ID: <8736k49c57.fsf@firstfloor.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dan Williams writes: > > The underlying issue is that the x86-PAT implementation wants to > ensure that conflicting mappings are not set up for the same physical > address. This is mentioned in the developer manuals as problematic on > some cpus. Andi, is lookup_memtype() and track_pfn_insert() still > relevant? There have been discussions about it in the past, and the right answer will likely differ for different CPUs: But so far the official answer for Intel CPUs is that these caching conflicts should be avoided. So I guess the cache in the original email makes sense for now. -Andi