WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] SMP designs and discuss

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] SMP designs and discuss
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Mon, 17 Oct 2005 17:08:14 +0200
Delivery-date: Mon, 17 Oct 2005 14:02:58 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD572F2D6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <516F50407E01324991DD6D07B0531AD572F2D6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Samedi 15 Octobre 2005 00:21, Magenheimer, Dan (HP Labs Fort Collins) a 
écrit :
[...]
> > * scheduler spin-lock.
> >   Currently, I use an hack to release the spin-lock acquired in
> >    __enter_schedule.  This is done in schedule_tail.
> >   The problem is during the first activation of a domain: the
> > spin-lock is
> >   acquired, but context_switch never returns, and on x86 the
> > spin-lock is
> >   released after context_switch.
>
> Not sure if there is a better solution than your hack but others
> may have suggestions.
Ok this issue may be closed.

> > * Idle regs.
> >   Currently, idle domains have no regs (the regs field is NULL).
> >   [I am not sure it is true for idle0].
> >   Is it a problem ?
> >   I had to modify the heartbeat so that it doesn't reference regs.
>
> Personally I don't think idle should exist, but it definitely
> shouldn't require state to be saved and restored.
Maybe true for idle0 but what do other processors execute when there is no 
domain ?

> > * Why xentime.c is so complicate ?
> >   What is the purpose of itc_at_irq, stime_irq ?
>
> Some of this is historical from my early attempts to leverage
> Linux code while merging in the necessary Xen code.  Time
> management needs to be rewritten but we have delayed working
> on it until higher priority tasks are done.
Ok

[...]
> > * VHPT
> >   How many VHPT per system ?
> >    1) Only one
> >    2) One per LP  (current design)
> >    3) One per VCPU (original Xen-VTI).
> >   I think (1) is not scalable...
>
> I thought the current design is (1).  Perhaps I didn't
> look closely enough at your SMP patch!
Well, the VHPT is allocated in mm_init, which is called once per cpu.

> There was some debate about this in April.  It started off-list
> but some of it is archived here:
> http://lists.xensource.com/archives/html/xen-ia64-devel/2005-04/msg00017
> .html
> We decided that different use models may require different
> VHPT models and that we would support both, at least so that
> we could measure them both.  This also hasn't been high priority
> as, until recently, we didn't have more than one LP or VCPU!
Ok, I will look the archives.

Tristan.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

<Prev in Thread] Current Thread [Next in Thread>