Date: Mon, 03 Dec 2007 18:40:34 +0300 From: Alexey Popov <lol@chistydom.ru> To: Robert Watson <rwatson@FreeBSD.org> 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: <47542372.3040303@chistydom.ru> In-Reply-To: <20071203114037.G79674@fledge.watson.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. 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? > 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. > 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. With best regards, Alexey Popov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47542372.3040303>