From owner-freebsd-current@FreeBSD.ORG Wed May 18 17:01:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E2A9106564A; Wed, 18 May 2011 17:01:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3982B8FC12; Wed, 18 May 2011 17:01:27 +0000 (UTC) Received: by pwj8 with SMTP id 8so1084977pwj.13 for ; Wed, 18 May 2011 10:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=lFG374beTWD8niyTMihkFgrXD5hw4AGaErMjy3i3syk=; b=ZPMbvhdWObaFcAtWLCg8fEZXli5rV54lUnsCNvVN9iUUUDuTw64FbI3vIeob5VE3zo E8BtoWwTUyt6mtcwMz/ven8Vhug/YGwIIZ1Bu+OU6PS0OccwQ18WSjJXtSjY1YCv3D5X 0VRcd45xbQ3zi2WhjY0oZhx6YTB+i0SuBpe4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=r2EkusCyAnYA8M2OFYywsebagFYn3823ZuaWXR7yZTsaaIuj4L5uq824nbHRtuhQnr 8jNtHIWKUEZQqedEpsmIc7R2M9xAbB5xeGaDaPkzGb28tjOBfcN/SIB5OOtigrpoVDod LYmKM7ePe/+kljQoeaVGeo5gOTRaV7lP4n0u4= Received: by 10.68.46.195 with SMTP id x3mr3173696pbm.442.1305737620640; Wed, 18 May 2011 09:53:40 -0700 (PDT) Received: from [192.168.20.56] ([24.6.49.154]) by mx.google.com with ESMTPS id b10sm1162323pbq.22.2011.05.18.09.53.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 09:53:39 -0700 (PDT) References: <4DD3F662.9040603@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Wed, 18 May 2011 09:53:34 -0700 To: Attilio Rao Cc: "freebsd-current@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:01:27 -0000 On May 18, 2011, at 9:49 AM, Attilio Rao wrote: > 2011/5/18 Garrett Cooper : >> On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon wrote: >>>=20 >>> I think that it is a well known fact that currently we do not have any s= upport for >>> dynamically offlining processors. Yet, we have some code that looks lik= e it does >>> provide that support and even provides a user interface to supposedly do= that. >>>=20 >>> 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... >>>=20 >>> 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 th= e >>> followups to the following PR: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145385 >>> And also discussed here: >>> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 >>>=20 >>> I think that there already have been a proposal to remove the systcls an= d 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 >>>=20 >>> 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 b= ig piece >>> of work and requires time and effort. >>=20 >> 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 >=20 > 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. >=20 > 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 4B= SD so as long as there is an equivalent tunable, that's good enough for us m= oving forward. Thanks! -Garrett=