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;
Subject: Re: [RFC PATCH 0/7] x86/intel_rdt: Restoration of Cache Pseudo-Locked
 regions
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     fenghua.yu@intel.com, Tony Luck <tony.luck@intel.com>,
        vikas.shivappa@linux.intel.com, gavin.hindman@intel.com,
        jithu.joseph@intel.com, dave.hansen@intel.com, mingo@redhat.com,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
References: <cover.1532463771.git.reinette.chatre@intel.com>
 <alpine.DEB.2.21.1808031343020.1745@nanos.tec.linutronix.de>
From:   Reinette Chatre <reinette.chatre@intel.com>
Message-ID: <05a621ec-adce-42b1-ea99-3bd8bac00e16@intel.com>
Date:   Fri, 3 Aug 2018 08:40:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.1808031343020.1745@nanos.tec.linutronix.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Thomas,

On 8/3/2018 4:45 AM, Thomas Gleixner wrote:
> On Tue, 24 Jul 2018, Reinette Chatre wrote:
>> A Cache Pseudo-Locked region is vulnerable to certain instructions (INVD,
>> WBINVD, CLFLUSH) or deeper C-states (that could shrink or power off the
>> cache) evicting the pseudo-locked memory. The current support for
>> pseudo-locked regions already restrict deeper C-states on cores associated
>> with the pseudo-locked regions, but the vulnerability to some instructions
>> remain.
>>
>> This work does not prevent the instructions to which Cache Pseudo-Locked
>> regions are vulnerable, instead, this work support the restoration of
>> Cache Pseudo-Locked regions that can be triggered manually by the user
>> or automatically after the WBINVD instruction has been issued.
>>
>> A new debugfs file "pseudo_lock_restore" is associated with each
>> pseudo-locked region and can be used to manually trigger the memory
>> associated with the region to be pseudo-locked to cache again.
> 
> I'm not seeing how that should be used. What's the indication for an
> operator to write to that file?

Our primary indicator would come from the debugfs mechanism that the
user can use to accurately measure how well the data is pseudo-locked.
If that shows that some cache misses are encountered then the user has
the option to lock the data again.

A user may measure the success of a pseudo-lock region right after its
creation or if any performance issues are experienced by the application
that depends on this region. The latter may hint that there could be as
issue with the integration with power savings, a desctructive
instruction made it to the system, or some other cause that needs to be
investigated.

>> The system-wide "native_wbinvd()" is modified to trigger the restoration of
>> all Cache Pseudo-Locked regions after the WBINVD instruction returns and
>> effort is made to avoid any unnecessary work in this flow.
>>
>> Within the kernel two locations with direct invocations of the WBINVD
>> instruction are coverted to native_wbinvd() and compile tested. Neither
>> location is likely to be used on the platforms supporting Cache Pseudo-Locking.
> 
> Can we just get rid of WBINVD?

While directed at me I am not able to answer this. native_wbinvd() is
used in a few areas that appear important to me.

Reinette