[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] x86/x2apic: properly implement cluster mode


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Thu, 08 Nov 2012 16:52:00 +0000
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Nov 2012 16:52:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac290V7Od5EmuJeaTEKGw1qhthRb6g==
  • Thread-topic: [Xen-devel] [PATCH 2/2] x86/x2apic: properly implement cluster mode

On 08/11/2012 15:38, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> On 08.11.12 at 16:17, Keir Fraser <keir@xxxxxxx> wrote:
>> On 08/11/2012 15:03, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> 
>>> So far, cluster mode was just an alternative implementation of
>>> physical mode: Allowing only single CPU interrupt targets, and sending
>>> IPIs to each target CPU separately. Take advantage of what cluster
>>> mode really can do in that regard.
>> 
>> What does it allow? Multicast within certain constraints?
> 
> For IPIs, yes. For interrupts, this gets things merely in line with
> cluster mode APIC, specifying more than one destination with
> lowest priority delivery. Without actively using the TPR, that
> should only affect nested interrupts (which previously would
> have got deferred until the outer one finished if their vector
> was a lower priority one than the one in service, whereas now
> they could get serviced by another CPU within the cluster).
>
> I also should have pointed out that this has a potential drawback
> - it might increase the pressure on vector allocation, since
> they're now being shared more heavily (within clusters). But if
> someone runs into problems with that, they ought to simply
> switch to physical mode (which previously really had no practical
> use at all).
> 
>> I know it's not
>> part of our coding style, but some comments would be nice. ;)
> 
> Hard to tell what specifically you would want to see commented,
> given that this really just extends the originally rather simplistic
> implementation.

Okay, yes, it doesn't look so complicated re-reading it again. I'm fine with
it as it is.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.