[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef39e053-ad81-2058-f66c-037f90b53516@intel.com>
Date: Tue, 15 May 2018 08:10:59 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Fenghua Yu <fenghua.yu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Tony Luck <tony.luck@...el.com>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Arjan van de Ven <arjan@...radead.org>,
Alan Cox <alan@...ux.intel.com>
Cc: x86 <x86@...nel.org>, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/15] x86/split_lock: Enable #AC exception for split
locked accesses
On 05/14/2018 11:52 AM, Fenghua Yu wrote:
> When executing an atomic instruction, sometimes the data access crosses
> the cache line boundary. This causes performance degradation. Intel
> introduces mechanism to detect such split lock issue via alignment check
> fault.
This is still a pretty sparse description.
Could you describe the performance degradation? Why is this not a
"doctor it hurts when I do that" situation?
Could you also give us *some* idea which CPUs this will show up on? Is
it a one-off feature, or will it be available widely?
> Since kernel doesn't know when SMI comes, it's impossible for kernel
> to disable split lock #AC before entering SMI. So SMI handler may
> inherit kernel's split lock setting and kernel tester may end up
> debug split lock issues in SMI.
What's a "kernel tester"?
Powered by blists - more mailing lists