Date: Tue, 4 Dec 2007 12:44:12 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Krassimir Slavchev <krassi@bulinfo.net> Cc: freebsd-stable@freebsd.org, Alexey Popov <lol@chistydom.ru> Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD Message-ID: <20071204123116.G87930@fledge.watson.org> In-Reply-To: <47554773.2080806@bulinfo.net> References: <20071201213732.GA16638@cannabis.dataforce.net> <1497741406.20071201230441@rulez.sk> <20071202174540.GA29572@cannabis.dataforce.net> <200712020844.49718.linimon@FreeBSD.org> <4753C9E4.1060200@chistydom.ru> <20071203114037.G79674@fledge.watson.org> <47542372.3040303@chistydom.ru> <20071203163353.J79674@fledge.watson.org> <47551C1C.3000903@chistydom.ru> <47553170.90409@bulinfo.net> <20071204121329.N87930@fledge.watson.org> <47554773.2080806@bulinfo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Dec 2007, Krassimir Slavchev wrote: >>>>> Evidence in-hand seems to suggest that 8 core systems work very well for >>>>> most users, and reflect a significant performance increase with 7.0 over >>>>> previous FreeBSD releases. >>>> >>>> I disagree with that. Heavily loaded Apache, MySQL, Postgres does not >>>> work well. >>> >>> There is another report for such problems: >>> >>> http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong >> >> A casual reading suggests that this article is about FreeBSD 6.2, and not >> FreeBSD 7.0. Am I misreading? > > No, But these tests can be performed on FreeBSD 7.0 4/8 core systems. These are precisely the sorts of tests we have been running. You can read a bit about the test in Kris's BSDCon.tr presentation: http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf We can't promise improvement on every workload, but we have seen real improvements on a great many workloads. I don't think anyone would argue that there isn't more work to be done, but at some point you have to stabilize and cut a release so that people can use something in the mean time. Releasing a perfect operating system in ten years helps no one. :-) The real issue at hand is whether we've hit a critical problem that justifies delaying the release in order to refine, test, and merge a change of a critical locking primitive in the kernel. Changing locking primitives, as I mentioned in an earlier post, is a risky thing: after all, it intentionally changes the timing for critical kernel data structures in the file system code. I've given Stephan, the author of the patch, a ping to ask him about this, but late in a release cycle, conservativism is the watch-word. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071204123116.G87930>