On Mon, May 27, 2019 at 6:18 PM Ipsen S Ripsbusker < [email protected]> wrote:
> Aaron Mason writes: > > Looks to me like you're not running bsd.mp. A dmesg would clear this > up. > > Indeed I was not running bsd.mp. I switched to bsd.mp, and then 2 of 4 > CPUs were online. Then I set "sysctl hw.smt = 1" to get all 4 online. > This is a side-point, but you do understand that those extra 2 aren't full CPUs, they're just the cardboard mockups that Intel sold you, and that if you run any untrusted code (including javascript in a web-browser) that those fake CPUs leak data across process boundaries, right? > Otto Moerbeek writes: > > On Sun, Apr 07, 2019 at 01:54:35PM +0000, Ipsen S Ripsbusker wrote: > > > ... > > > Also, now that I have realized this, I have a theory about a related > > > issue, and I would like to know how I can debug it. I am using softraid > > > CRYPTO, and I have found that accessing the disk with one process will > > > interrupt the other processes accessing the disk. Now I wonder this > > > happens because the sole core must switch encryption/decription > > > processes for the different files. How could I determine whether this > is > > > indeed happening? > Can you explain in more detail what you were observing when you said "found that accessing the disk with one process will interrupt the other processes accessing the disk"? The word 'interrupt' is overloaded in computing and what you saw may be a real problem with device support, or it may be completely innocuous, something which you should be ignoring. Philip Guenther
