On Sun, Dec 16, 2018 at 09:27:46AM +0100, Greg KH wrote: > On Sun, Dec 16, 2018 at 02:21:55PM +0800, Barry Kauler wrote: > > Mr Gleixner, > > I was upset when I compiled 4.14.87 found that SCHED_SMT had been > > forced on. At the time, I just reported it to my blog, and posted a > > question about it to a couple of forums, and stayed with an earlier > > kernel. > > > > However, when 4.14.88 came out, and still the same situation, alarm > > bells went off, and I looked through the kernel changelog. Found it, > > 4.14.86: > > > > "x86/Kconfig: Select SCHED_SMT if SMP enabled" > > > > Then: > > > > "CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to > > have it configurable. ..." > > > > ...that is a lie. It would be correct to state that is true of the > > distros you use, and presumably also for all of you guys who signed > > off on it. > > > > Puppy Linux is an example of a distro that has mostly not had > > SCHED_SMT enabled. Ditto for most of the forks of Puppy. Two distros > > that I currently maintain, Quirky and EasyOS (easyos.org) have SMP > > enabled but not SCHED_SMT. > > > > The difference between them is important, they should remain > > independently settable. I am so surprised that all of you guys went > > along with forcing it on. > > Is having this option enabled causing a problem for you? Does it cause > slowdowns or runtime issues? >From the blog: >>> Note, way back in the early days when I was first compiling the kernel for multi-core CPUs, SMT (hyperthreading), which simulates more than one core for each actual core, was causing file corruption. So, disabled it, and never trusted it after that. << Since nearly everyone else has the option enabled we are quite confident there is no data corruption caused by it. So there shouldn't be any reason to turn it off. -Andi
