[rfc] remove hlt_cpus et al sysctls and related code
avg at FreeBSD.org
Mon May 23 16:28:30 UTC 2011
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 at 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
> 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
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.
More information about the freebsd-arch