2011/5/18 Garrett Cooper <yanegomi_at_gmail.com>: > 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. 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. 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. Attilio -- Peace can only be achieved by understanding - A. EinsteinReceived on Wed May 18 2011 - 15:04:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC