On Mon, 3 Dec 2007, Alexey Popov wrote:
Robert Watson wrote:
Is there any other FreeBSD developer who can take care of performance
problems on many-cores systems? Seems like upcoming 7-RELEASE and
6.3-RELEASE would be completely unusable for us on that kind of systems
i.e. mostly on all modern hardware.
There are many FreeBSD developers who care a great deal about the
performance of many-core systems. However, it's also very late in the
release cycle for 7.0, and this sort of analysis requires a lot of time, so
I don't think we will (or should) see any substantial changes at this point
as they would require us to significantly extend the release cycle in order
to test them properly.
Is there a reason to release system that unable to work on 8-core systems?
What would people think when they won't be able to run their old projects
after moving to the new hardware?
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. Obviously, this is not true in all cases, but part of the
point of doing a .0 release is to get the technology into the hands of people
who want to use it, and part of the point of continuing to support the 6.x
release series is to provide the less agressive feature development that some
users needed.
The right path forwawrd at this point is to diagnosis the problems and
work on fixing them in 8-CURRENT, and assuming they are not highly
disruptive, MFC them for FreeBSD 7.1.
I believe at least the bug with lockmgr contention should be fixed before
release.
Could you point me at the specific proposed change in question? I don't think
I've seen it come across re@ as a potential merge request. Changing locking
primitives close to a release is, FYI, a risky business, as while it may
improve performance in specific cases, we may not have a lot of information
about more general cases. We also risk opening up previously nascent race
conditions in lock consumers.
In general, the most important factor in optimizing performance is to get a
good collaboration going between someone who can reproduce the problem,
ideally in a way that can be shared with developers so they can also
reproduce the problem, and provide testing and feedback over an extended
period (several months) while the changes are developed and refined. This
is part of the role Kris has been playing with a number of FreeBSD
developers -- Jeff, Attilio, myself, etc -- he set up highly reproduceable
performance measurements and then worked with us to evaluate various
patches to improve performance. That kind of dynamic is invaluable, but it
requires users who care a lot about performance (or whatever other factor
it is) to spend a fair amount of time helping us. Whether this is by
providing a potted benchmark for developers to try out, or if this is by
providing access to the test environment on their own systems, it's still
critical. I know from previous messages in the thread that you can't
provide access to the actual application, but can you provide some sort of
potted substitute that has similar performance properties -- be it php page
sizes, database query load traces that can be replayed, etc?
I can try to produce synthetic benchmarks based on my workload but really
I'm interested more in real workload performance. I'm ready to test changes,
measure differences and provide any benchmark and profiling information.
Except for lockmgr contention bug there seems to be a much optimization work
to do because FreeBSD with patched lockmgr on my workload is still 1.5 times
slower that Linux.
Obviously, we are interested in the real workload also, but there are times
when we have to accept synthetic benchmarks we can get our hands on instead of
real benchmarks that people won't give to us because they incorporate
proprietary technology, business-sensitive information, or are simply too
complex to reproduce, etc. If you can give us the exact workload to reproduce
on our systems, that's much better than a synthetic benchmark, but if you
can't, then a synthetic benchmark is what we'll have to work with.
I suggest we move this thread to the performance@ mailing list, and if
possible, could you begin the thread over there with a summary of the workload
and investigation to date.
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]"
