From owner-cvs-src@FreeBSD.ORG Sat Nov 10 15:32:21 2007 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4003516A417; Sat, 10 Nov 2007 15:32:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCCC713C4AA; Sat, 10 Nov 2007 15:32:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0F5BF46DE1; Sat, 10 Nov 2007 10:33:04 -0500 (EST) Date: Sat, 10 Nov 2007 15:31:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4735CC65.50400@elischer.org> Message-ID: <20071110152850.O29504@fledge.watson.org> 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> <20071110190555.I35816@delplex.bde.org> <47357937.6080400@FreeBSD.org> <4735CC65.50400@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Maxim Sobolev , src-committers@FreeBSD.org, Bruce Evans , cvs-src@FreeBSD.org, Kris Kennaway , cvs-all@FreeBSD.org, Colin Percival , Nate Lawson Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2007 15:32:21 -0000 On Sat, 10 Nov 2007, Julian Elischer wrote: > Maxim Sobolev wrote: >> Bruce Evans wrote: >>> Off is a good default since hyperthreading seems to be a pessimization in >>> most casts. >> >> Well, actually it all depends on workload and scheduling. I believe ULE is >> expected to improve things quite a bit in scheduling department. However, >> even with ol'good SCHED_BSD we measured noticeable performance increase >> (15-25%) in CPU intensive real-world tasks with HTT enabled on 2-way SMP >> Xeon system. It was in 2004, both CPUs and schedules should have been >> improved since that time. > > Vicor (where I used to work) noticed recently that newer systems were > getting much less work done thann their older bretheren. On investigation > they found that it was because the newer systems had HT turned off.. Their > workload is a mix of FP and Int crunching in image processing and just > happens to be the near perfect HT workload. With 2 x HT processors (4 > logical processors), they could get about 3.7 times the throughput of a > single processor in tests I did in 04 or so. > > However for most other loads HT turned out to be at best a wash and at worst > a slight loss, so having it off will help the average user I think. This used to be the wisdom, but more recent testing has shown that HTT is at worst a break-even and often a performance improvement--presumably some of this is a result of better SMP support in FreeBSD, but some is also an improvement of the basic HTT technology. A significant factor has been the replacement of the P4 Xeon line from Intel, which had extortionately high synchronization costs--more recent processors behave a lot better. While we can make legitimate security arguments for/against HTT, I think the intuitive "but it's a bad idea anyway so it doesn't hurt to turn it off" thinking regarding HTT is no longer valid. To be specific, turning off HTT may lead to modest or significant performance loss for our users. Robert N M Watson Computer Laboratory University of Cambridge