From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: heap_lock optimizations? Date: Mon, 15 Jul 2013 17:09:40 +0100 Message-ID: <20130715160940.GA6719@ocelot.phlegethon.org> References: <20130715151525.GG4817@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130715151525.GG4817@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Malcolm Crossley , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hi, At 11:15 -0400 on 15 Jul (1373886925), Konrad Rzeszutek Wilk wrote: > Hey Tim, > > I was looking at making the 'Scrubbing Free RAM:' code faster on 1TB > boxes with 128 CPUs. And naively I wrote code that setup a tasklet > on each CPU and scrub a swatch of MFNs. Unfortunatly even on 8VCPU > machines the end result was a slower boot time! > > The culprit looks to be the heap_lock that is taken and released > on every MFN (for fun I added a bit of code to do batches - of > 32 MFNs and to iterate over those 32 MFNs while holding the lock - that > did make it a bit faster, but not by a much). > > What I am wondering is: > - Have you ever thought about optimizing this? If so, how? Malcolm Crossley posted an RFC patch a while ago to do this kind of stuff -- parcelled out RAM to socket-local CPUs and IIRC took the heap-lock once for all on the coordinating CPU. http://lists.xen.org/archives/html/xen-devel/2012-05/msg00701.html AIUI he's going to send a v2 now that 4.3 is done. Tim.