From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Priority for SMP VMs Date: Tue, 22 Jul 2008 08:59:25 -0700 Message-ID: <488603DD.5080009@goop.org> References: <7a88c6510807021936g40635d18qaebff94e9267ce35@mail.gmail.com> <200807212200.51784.mark.williamson@cl.cam.ac.uk> <7a88c6510807212043y39523f8dv8976f9b1d10a1310@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: Mark Williamson , xen-devel@lists.xensource.com, Gabriel Southern List-Id: xen-devel@lists.xenproject.org George Dunlap wrote: > If you want a "clean" scheduler test, you should instead run "while(1) > ;" loops, which will never block, and will always consume all cpu time > available. My guess is if you do that, then the cpu time given to > each domain will be exactly according to their weight. On the other > hand, if you do a "kernbench" test, which will include a lot of > blocking, I suspect you may get even more disparity between the > runtimes. > My experience is that kernbench, if run properly, should not block. It precaches the source in memory before starting, so it should not generate any reads during a benchmark run. It will still write the build products, but write-behind should make that non-blocking from the benchmark's perspective. Running the maximal "make -j" test without enough memory will drive the machine into swapstorm, which will definitely block, but you're supposed to run with enough memory to avoid that (~4G bytes, I think). J