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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"