Date: Mon, 3 Dec 2007 16:39:02 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alexey Popov <lol@chistydom.ru> Cc: freebsd-stable@freebsd.org, Alexey Vlasov <renton@df.ru>, Mark Linimon <linimon@FreeBSD.org> Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD Message-ID: <20071203163353.J79674@fledge.watson.org> In-Reply-To: <47542372.3040303@chistydom.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071203163353.J79674>