From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emmanuel Ackaouy Subject: Re: [PATCH][RFC] consider vcpu-pin weight on CreditScheduler TAKE2 Date: Wed, 27 Jun 2007 14:21:54 +0200 Message-ID: <54544386934904fcb51d4ece80ca9db9@gmail.com> References: <4670ea394e9afc4df54c0595a807c031@gmail.com> <200706271207.l5RC7SDD001615@fjmscan501.ms.jp.fujitsu.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200706271207.l5RC7SDD001615@fjmscan501.ms.jp.fujitsu.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: Atsushi SAKAI Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Jun 27, 2007, at 14:07, Atsushi SAKAI wrote: > Thank you for commenting my patch. > I am waiting for this kind of discussion. > > My patch is a kind of full-set solution for this vcpu-pin weight issue. > Of couse, your suggested complex configuration considers it. > Since my patch is calculate each pcpu credit. > (It makes a kind of long code((+)365line)). > > Anyway your suggested, > Segmenting pcpu is another useful solution. > Since in typical use, seg-1 for dev seg-2 for rest. > But flexibility is reduced from previous one. > In this case vcpu-pin cannot define over the multiple segmentation. > > Which is the best way to solve? If you could solve the generic problem in a simpler way, I would not be opposed to it. But +365 lines in what is already a fairly complex accounting code path doesn't seem right to me. I can't even understand what weights mean when every CPU has a different pin cpumask. Weights only make sense to me when VMs compete for resources. In my opinion, adding the concept of dynamic partitioning (or segmentation) of the host system would allow a bunch of people to no longer have to pin their VCPUs. This is desirable.