Re: [rfc] remove hlt_cpus et al sysctls and related code

On May 18, 2011, at 9:49 AM, Attilio Rao <attilio_at_freebsd.org> wrote:

> 2011/5/18 Garrett Cooper <yanegomi_at_gmail.com>:
>> On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon <avg_at_freebsd.org> wrote:
>>> 
>>> I think that it is a well known fact that currently we do not have any support for
>>> dynamically offlining processors.  Yet, we have some code that looks like it does
>>> provide that support and even provides a user interface to supposedly do that.
>>> 
>>> What we don't currently do specifically:
>>> - rebinding interrupts away from an offlined processor
>>> - updating relevant cpu sets and masks
>>> - protecting the above for concurrent access
>>> - moving threads away from an offlined processor
>>> - notifying potentially interested parties
>>> - maybe more...
>>> 
>>> The code has been in this shape for a long while and I would dare to say that it
>>> never really worked, not in "production ready" sense anyway.
>>> An example of troubles caused by using that code can be found e.g. in the
>>> followups to the following PR:
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=145385
>>> And also discussed here:
>>> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=74510
>>> 
>>> I think that there already have been a proposal to remove the systcls and the
>>> code.  I would like to re-submit that proposal.
>>> Removing that code would:
>>> 1) prevent users from hurting themselves by executing broken code
>>> 2) potentially make things easier for largeSMP project
>>> 
>>> Once we grow correct code for offlining CPUs, then we could re-introduce the
>>> sysctls without any problems.
>>> While the offlining code doesn't seem terribly hard to develop, it's a big piece
>>> of work and requires time and effort.
>> 
>>    What would be nice too (even though it might not be possible) is
>> to make this more MI than it is today (i.e. sysctls that work for
>> amd64, sparc64, etc), but that might be a pipe dream.
>> Thanks!
>> -Garrett
> 
> That is actually the purpose.  We should have a real online/offline
> system for hotplugging CPUs, not only tied to x86 hyperthreading.
> The htt specific parts are mostly hacks that don't take into account
> all the necessary handover for it.
> 
> Andryi, I'll look into the patch asap, but I'm in favor of this change for sure.

    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.
Thanks!
-Garrett