From mboxrd@z Thu Jan 1 00:00:00 1970 From: NISHIGUCHI Naoki Subject: Re: [RFC][PATCH] scheduler: credit scheduler for client virtualization Date: Fri, 05 Dec 2008 12:17:36 +0900 Message-ID: <49389D50.60309@jp.fujitsu.com> References: <49364960.2060101@jp.fujitsu.com> <49378C16.1040106@jp.fujitsu.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 , xen-devel@lists.xensource.com Cc: Ian.Pratt@eu.citrix.com, disheng.su@intel.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org Thanks for your information. George Dunlap wrote: > There was a paper earlier this year about scheduling and I/O performance: > http://www.cs.rice.edu/CS/Architecture/docs/ongaro-vee08.pdf > > One of the things he noted was that if a driver domain is accepting > network packets for multiple VMs, we sometimes get the following > pattern: > * driver domain wakes up, starts processing packets. Because it's in > "over", it doesn't get boosted. > * Passes a packet to VM 1, waking it up. It runs in "boost", > preempting the (now lower-priority) driver domain. > * Other packets (possibly even for VM 1) sit in the driver domain's > queue, waiting for it to get cpu time. I don't read the paper yet, but I think our approach is effective in this problem. However, if driver domain consumes cpu time too much, we couldn't prevent it from becoming "over" priority. Otherwise, we could keep it with "under" or "boost" priority. > Their tests, for 3 networking guests and 3 cpu-intensive guests, > showed a 40% degradation in performance due to this problem. While > we're thinking about the scheduler, it might be worth seeing if we can > solve this. Firstly, I'd like to read the paper. Regards, Naoki Nishiguchi