From owner-freebsd-arch@FreeBSD.ORG Wed May 18 17:04:14 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64D3106564A; Wed, 18 May 2011 17:04:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3156A8FC08; Wed, 18 May 2011 17:04:14 +0000 (UTC) Received: by vxc34 with SMTP id 34so1750361vxc.13 for ; Wed, 18 May 2011 10:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CQIaPuMYI9b7eS795opJ4SRZNJfv/Ta3oH9sN6WBzi8=; b=lnTD3/FXWxfk9IN5E1shaMhrPUu/IlWHJjaYaJEcpyccfTvXZkmnBPtFIvO7+M9Vx7 bTF/mkNXWerEtbETIQ8Vepi9jxSEDVbbgBOTkjGMzstoW/qlSq7qmzON3m71kHHTUznX Kvf3mkLg7y9PkvImvgeY13S1jzn8RMghoeYgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hU1RT7Zub8Dp6V7xENOzW8AS1JhNzbls9VuRxj9AfEvDJUtXHfLXSiokP5Y2HMJJtO YCAxTfkyx+35gusZFjaC2DKGzgZTMwEvdP/T4/eZubz41mxhj/wOQUHCpf9Qk6nsiDPa u3fi1esIbdP36oUkqDvJJ2tuaf/+QaTaMXkEA= MIME-Version: 1.0 Received: by 10.52.95.203 with SMTP id dm11mr3010286vdb.213.1305738253465; Wed, 18 May 2011 10:04:13 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.220.201.3 with HTTP; Wed, 18 May 2011 10:04:13 -0700 (PDT) In-Reply-To: References: <4DD3F662.9040603@FreeBSD.org> Date: Wed, 18 May 2011 13:04:13 -0400 X-Google-Sender-Auth: WR1UlXTHniDXxPwzAE-lGuHJEXw Message-ID: From: Attilio Rao To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:04:14 -0000 2011/5/18 Garrett Cooper : > 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: >>>> >>>> I think that it is a well known fact that currently we do not have any= support for >>>> dynamically offlining processors. =C2=A0Yet, we have some code that lo= oks 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 s= ay 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=3D145385 >>>> And also discussed here: >>>> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 >>>> >>>> I think that there already have been a proposal to remove the systcls = and the >>>> code. =C2=A0I 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-introdu= ce 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. >>> >>> =C2=A0 =C2=A0What would be nice too (even though it might not be possib= le) 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. =C2=A0We 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 f= or sure. > > =C2=A0 =C2=A0We 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 en= ough 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 --=20 Peace can only be achieved by understanding - A. Einstein