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

2011/5/18 Attilio Rao <attilio_at_freebsd.org>:
> 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.

For instance, I always promised to implement them and I never did,
mostly because it is quite a bit of work in my idea and we don't
really have a big pressure for it and there are really bigger things
on my plate.

If someone wants to step up and implementing offline/online CPUs I
would be glad to discuss approaches I have in mind and help
formalizing a plan for it, thus offering guidance for the
implementation.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein