Date: Mon, 23 Feb 2009 06:05:36 -0800 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Jeff Roberson <jeff@FreeBSD.org>, "current@freebsd.org" <current@FreeBSD.org>, stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 Message-ID: <49A2AD30.1040007@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org> References: <49A23C1A.3070403@FreeBSD.org> <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Sun, 22 Feb 2009, Maxim Sobolev wrote: > >> Hi Jeff, >> >> I have a single-CPU system with P4 HTT-enabled processor >> (7.1-RELEASE-p3), kernel compiled with SCHED_ULE. > > This is because machdep.hlt_logical_cpus doesn't do what you think it > does. It causes HTT cores to invoke the hlt instruction in their idle Hmm, as the subject says I am actually talking about flipping machdep.hyperthreading_allowed, not machdep.hlt_logical_cpus sysctl here. I provided current value of the latter only to simplify diagnosis and had not changed it from the default value. AFAIK, the machdep.hyperthreading_allowed is designed to prevent logical cores from running any code, works just fine with 6.x/SCHED_4BSD. Below are screenshots from the dual-core 6.2 system with 4BSD. As you can easily see, after flipping machdep.hyperthreading_allowed only cores 0 and 2 run actual code, so that it's definitely regression of ULE/7.x: machdep.hyperthreading_allowed=1: top: http://sobomax.sippysoft.com/~sobomax/ScreenShot462.png machdep.hyperthreading_allowed=0: top: http://sobomax.sippysoft.com/~sobomax/ScreenShot463.png IMHO, at the very least, if SCHED_ULE doesn't support machdep.hyperthreading_allowed properly, then when that scheduler is selected the sysctl should return ENOTSUP or something like this. -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49A2AD30.1040007>