From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH 7/7] xen: sched_rt: print useful affinity
	info when dumping
Date: Tue, 17 Mar 2015 11:10:49 +0000
Message-ID: <55080BB9.3050005@eu.citrix.com>
References: <20150316165642.10279.86684.stgit@Solace.station>
	<20150316170544.10279.13073.stgit@Solace.station>
	<CAENZ-+nPXvpNwwcZhKzP-BaW42TissgjbUKKawCtV9YD79qRww@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAENZ-+nPXvpNwwcZhKzP-BaW42TissgjbUKKawCtV9YD79qRww@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Meng Xu <xumengpanda@gmail.com>, Dario Faggioli <dario.faggioli@citrix.com>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 03/16/2015 08:30 PM, Meng Xu wrote:
> Hi Dario,
> 
> 2015-03-16 13:05 GMT-04:00 Dario Faggioli <dario.faggioli@citrix.com>:
>> In fact, printing the cpupool's CPU online mask
>> for each vCPU is just redundant, as that is the
>> same for all the vCPUs of all the domains in the
>> same cpupool, while hard affinity is already part
>> of the output of dumping domains info.
>>
>> Instead, print the intersection between hard
>> affinity and online CPUs, which is --in case of this
>> scheduler-- the effective affinity always used for
>> the vCPUs.
> 
> Agree.
> 
>>
>> This change also takes the chance to add a scratch
>> cpumask, to avoid having to create one more
>> cpumask_var_t on the stack of the dumping routine.
> 
> Actually, I have a question about the strength of this design. When we
> have a machine with many cpus, we will end up with allocating a
> cpumask for each cpu. Is this better than having a cpumask_var_t on
> the stack of the dumping routine, since the dumping routine is not in
> the hot path?

The reason for taking this off the stack is that the hypervisor stack is
a fairly limited resource -- IIRC it's only 8k (for each cpu).  If the
call stack gets too deep, the hypervisor will triple-fault.  Keeping
really large variables like cpumasks off the stack is key to making sure
we don't get close to that.

Systems with a lot of cpus can also be assumed I think to have a lot of
memory, so having one per cpu shouldn't really be that bad.

 -George