From owner-cvs-all@FreeBSD.ORG Sun Nov 11 18:22:55 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E32A16A417 for ; Sun, 11 Nov 2007 18:22:55 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BED0313C4BF for ; Sun, 11 Nov 2007 18:22:54 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 29774 invoked from network); 11 Nov 2007 18:22:43 -0000 Received: from unknown (HELO ?192.168.1.77?) (nate-mail@71.141.139.72) by root.org with ESMTPA; 11 Nov 2007 18:22:43 -0000 Message-ID: <47374870.1080706@root.org> Date: Sun, 11 Nov 2007 10:22:40 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Colin Percival References: <200711081945.lA8JjKcW080540@repoman.freebsd.org> <47337724.9040108@FreeBSD.org> <47337940.6040909@root.org> <47340B74.9070004@freebsd.org> <4734B13C.6050008@root.org> <4735008D.7030600@FreeBSD.org> <473667FF.2010005@freebsd.org> In-Reply-To: <473667FF.2010005@freebsd.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , Kris Kennaway , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 18:22:55 -0000 Colin Percival wrote: > Maxim Sobolev wrote: >> By the way, I wonder how sun4v (aka Niagara) fares in this respect. As >> long as I know, they use similar concept, when 8 physical cores can run >> 32 threads. Should we disable it by default there as well? ;-) > > I haven't seen any experiments done on sun4v, but I'm less concerned about > it since I believe sun4v boxes are used more often for large computing jobs > rather than for interactive logins with many untrusted users. Of course, > if/when we have scheduler support for keeping different users on separate > cores, this should be applied to sun4v as well. I don't think locking threads to cores by uid solves the general problem. Consider a web server, where processes run as the same uid but represent different customers. What we need is for the software components that deal with secrets (keys, passwords, etc.) to be able to specify "don't switch me out until I'm done" for a short quantum. Restricting access to that mechanism would also be needed to prevent DoS, same as realtime scheduling. -- Nate