2011/5/18 Garrett Cooper <yaneg...@gmail.com>: > On May 18, 2011, at 9:49 AM, Attilio Rao <atti...@freebsd.org> wrote: > >> 2011/5/18 Garrett Cooper <yaneg...@gmail.com>: >>> On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon <a...@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. Einstein _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
