Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 May 2011 19:28:26 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Attilio Rao <attilio@FreeBSD.org>
Cc:        Garrett Cooper <yanegomi@gmail.com>, "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.org>, "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org>
Subject:   Re: [rfc] remove hlt_cpus et al sysctls and related code
Message-ID:  <4DDA8B2A.6010500@FreeBSD.org>
In-Reply-To: <4DD54C18.8050305@FreeBSD.org>
References:  <4DD3F662.9040603@FreeBSD.org>	<BANLkTikOTe9ut3GFx0bhOernKandRGLhPg@mail.gmail.com>	<BANLkTinVGrLoAOS_ZQ1YVB_Fw1cvf5kHyA@mail.gmail.com>	<BBCD9D8C-FCAF-4DE3-9F66-4B65AAABE67B@gmail.com> <BANLkTikMZ_xs4WCJVJG4oHe3rOKU8rqfVw@mail.gmail.com> <4DD54C18.8050305@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
on 19/05/2011 19:58 Andriy Gapon said the following:
> on 18/05/2011 20:04 Attilio Rao said the following:
>> 2011/5/18 Garrett Cooper <yanegomi@gmail.com>:
>>> We use this internally at work still with a software config that uses 4BSD so
>>> as long as there is an equivalent tunable, that's good enough for us moving
>>> forward.
> 
> Can you please clarify which exactly tunable(s) do you use/need?
> Just turning hyperthreading on/off or more?  (BTW, doing that via BIOS is
> inconvenient / not feasible?)
> 
> BTW, I think that if we switch hyperthreading off then we better off not sending
> Start IPI to the logical CPUs at all.
> 
>> Tunables are pretty much acceptable for this case. What is really broken is the
>> on-the-fly ability to mark CPUs active/inactive and subsequent handovers.
> 
> Yes, I completely agree.  Static disabling of CPUs doesn't have any problems, and
> IMO, currently the best way to do it is with hint.lapic.X.disabled.
> 
>> I thought Andriy attached a patch to the tree, but it doesn't seem so...
>> anyway, yes, I think that adding tunables for this is very reasonable and not
>> as dangerous as the current mechanism.
> 
> I agree.
> I haven't sent a patch, because I don't have it yet :)
> I decided to solicit opinions before getting to hacking code.
> 

I propose the following path for moving forward.
- use hint.lapic.X.disabled to disable individual CPUs by their APIC ID
- use machdep.hyperthreading_allowed tunable to disable second logical CPU on each
real core

The above should already work as expected.  One thing is that currently we have
handling of machdep.hyperthreading_allowed tunable under SCHED_ULE.  I plan to
make it unconditional.

Things to remove:
- all the related sysctls for dynamic onlining/offlining
- machdep.hlt_logical_cpus tunable (it duplicates hint.lapic.X.disabled)

It's possible to keep machdep.hlt_logical_cpus and just add some code to convert
hlt_logical_cpus mask to a set of individual hint.lapic.X.disabled, but I don't
see very much value in that.  But if there is a good reason to keep that tunable,
I am prepared to jump through this hoop.

If no one objects to this proposal, I will provide a patch soon.
Thank you.
-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDA8B2A.6010500>