From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Xiaowei" Subject: Re: [PATCH] Add migration_cost option to scheduler Date: Tue, 10 Mar 2009 11:36:38 +0800 Message-ID: <49B5E046.7090406@intel.com> References: <49B4D0C8.5050504@intel.com> <0A882F4D99BBF6449D58E61AAFD7EDD606C4ECE3@pdsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0A882F4D99BBF6449D58E61AAFD7EDD606C4ECE3@pdsmsx502.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" Cc: 'George Dunlap' , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Tian, Kevin wrote: >> From: George Dunlap >> Sent: Monday, March 09, 2009 8:56 PM >> >> Hmm, I think this patch may not be exactly what we want. It looks >> like it checks for how long a vcpu has been in its current stat, not >> how recently it has been running. So if a vcpu sleeps for a long time >> on a cpu that's running other workloads, then wakes up >> (blocked->runnable), the cache is by no means "hot". But since it has >> only been in the "runnable" state for a few hundred cycles, it won't >> be migrated, even though there's little cost. > > Then to add a per-vcpu last_running_timestamp which is recorded when > vcpu is scheduled out, could hit the purpose here? Yes, it's more reasonable. I can make a patch. Thanks, xiaowei > >> However, if the pcpu was idle since the last time this vcpu ran (i.e., >> if we're just catching the vcpu in the process of waking up), the >> cache *is* still hot. Hmm.... >> > > If peer pcpu is idle, shouldn't it be skipped by load balancer running on > another pcpu, which is out of the cache-hot logic? > > Thanks, > Kevin