On 2/5/19 12:48 AM, Peter Zijlstra wrote: > On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote: >> So, the compromise we reached in this case is that Intel will fully >> document the future silicon architecture, and then write the kernel >> implementation to _that_. Then, for the weirdo deployments where this >> feature is not enumerated, we have the setcpuid= to fake the enumeration >> in software. > > What user is _EVER_ going to use this? Nobody, I expect the answer to > be.
This is one of the few times that we're pretty confident that folks will use this. The reason we're going to this trouble is that the split lock detection is wanted by actual customers, and they want it before it's implemented on a processor with real enumeration. This isn't something we want everybody and their grandma to turn on; it's a rather specialized feature. It's really only for folks that care about the latency incurred across the entire system on split lock operations. > Is this some transient state; where a few (early) models will not have > the enumeration sorted but all later models will have it all neat and > tidy? >From my understanding, it's not just an early stepping. It's a generational thing. The current generation lacks the enumeration and the next generation will get it. Both have the silicon to implement the feature itself. > If so, we can easily do the FMS solution for this. Yeah, we can. I honestly forget why we didn't do FMS. :) Fenghua? > But a cmdline features thing is not something I can see anybody but > a limited set of developers ever using. It's not for developers. This really is for (somewhat niche) end users that want split lock detection in production. This is all really an effort to get them running mainline or real distro kernels.
