[MODERATED] Re: ***UNCHECKED*** Re: Re: [PATCH 3/9] TAA 3
Michal Hocko <[email protected]> Fri, 1 Nov 2019 19:42:21 +0100
| Newsgroups | org.kernel.lore.historical-speck |
|---|---|
| Message-ID | <[email protected]> |
On Fri 01-11-19 10:35:26, speck for Greg KH wrote: > On Wed, Oct 30, 2019 at 08:44:40PM +0100, speck for Michal Hocko wrote: > > On Wed 30-10-19 20:27:58, speck for Greg KH wrote: > > > On Wed, Oct 30, 2019 at 10:24:03AM -0700, speck for Pawan Gupta wrote: > > > > On Wed, Oct 30, 2019 at 02:28:58PM +0100, speck for Greg KH wrote: > > > > > On Wed, Oct 23, 2019 at 11:01:53AM +0200, speck for Pawan Gupta wrote: > > > > > > From: Pawan Gupta <[email protected]> > > > > > > Subject: [PATCH 3/9] x86/cpu: Add a "tsx=" cmdline option with TSX disabled by > > > > > > default > > > > > > > > > > > > > > > > As late at this is, I really would like to change the name here. We > > > > > already have a powerpc command line option to disable this for those > > > > > chips, and we should use the same name here as well. > > > > > > > > I think powerpc calls it "ppc_tm=". We can't obviously change to this. > > > > > > > > ppc_tm= [PPC] > > > > Format: {"off"} > > > > Disable Hardware Transactional Memory > > > > > > No, but we can use "tm", and PPC said they would drop the "ppc_" prefix > > > and use the generic flag as well. "Transactional Memory" is the generic > > > term for this from what I can tell. > > > > Are those two (tsx and tm) going to have the same semantic? I have > > little doubts TBH considering how tsx itself is tricky. > > Ugh, turns out gmail was marking all of these threads as spam, that > answers my "why is this list so quiet?" question :( > > Anyway, yes, TM shoudl have the same semantic. My current understanding is that there is no way to simply disable tsx by the tsx parameter in general. I have no idea whether the same is the case for the ppc side of matters but I would be really surprised if the story was consistent with x86. Anway if there is a way to make this more consistent then I have no objections but please keep in mind that last minute changes this late are not really healthy tend to cause more harm then good. This is an architecture specific problem and attaching it as such first makes a lot of sense to me. Thanks! -- Michal Hocko SUSE Labs