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][PATCH][VTD] small patches for VTD

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel][PATCH][VTD] small patches for VTD
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Wed, 22 Oct 2008 16:05:13 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 22 Oct 2008 00:05:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <F7C8A4D3A9905B45A80E4C194793FA6501B3131519@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <F7C8A4D3A9905B45A80E4C194793FA6501B3130ED5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081022053201.GE8110%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501B3131460@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081022060621.GF8110%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501B3131491@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081022062633.GG8110%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501B31314C8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081022064042.GH8110%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501B3131519@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Wed, Oct 22, 2008 at 02:50:40PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Wed, Oct 22, 2008 at 02:30:50PM +0800, Xu, Anthony wrote:
> >> Isaku Yamahata wrote:
> >>> On Wed, Oct 22, 2008 at 02:11:52PM +0800, Xu, Anthony wrote:
> >>>> Isaku Yamahata wrote:
> >>>>> On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
> >>>>>> Yes, it is not SMP-safe there is lock for p2m.
> >>>>>> Modifying p2m is not a frequent operation, why not add a lock for
> >>>>>> it?
> >>>>>
> >>>>> It is frequent to read p2m table. So lockless approach was adopted
> >>>>> for scalability. It doesn't make sense to lock around only writer
> >>>>> side.
> >>>>>
> >>>>
> >>>> If only add write lock for p2m, is there any bad impact/senario?
> >>>> Can you explain more details?
> >>>
> >>> Generally lock should protect both readers and writers.
> >>> So locking around only writers doesn't make sense.
> >>
> >>
> >> So you can use read/write lock, multiple reader one writer.
> >> Because write is very rare, it will not impact performance, but it
> >> makes code in mm.c clear and easy to modify. I think that's why
> >> read/write lock exist.
> >
> > Yes, that's quite right.
> > It's another discussion to go for reader/writer lock or
> > to keep the current lockless approach.
> 
> If we want to keep the current lockless approach, we need to
> use ptep_cmpxchg_rel as less as possible
> 
> Currently there are four functions using ptep_cmpxchg_rel.
> assign_domain_page_cmpxchg_rel
> zap_domain_page_one
> replace_grant_host_mapping
> __assign_domain_page
> 
> And the four functions have similar function.
> 
> I suggest implementing below code segment as a core function
> __replace_domain_page(){
> 
> old_pte = ptep_xchg_rel();
> If(old_pte is INVALID)
> {
> }
> Elseif( old_pte is _PAGE_IO)
> {
> }
> Else if (old_pte is assigned_MMIO_page)
> {
> }
> Else if ( old_pte is normal page)
> {
>         put_page( old_page)
> }
> .....
> 
> We need to fully consider the old_pte type.
> 
> Other functions are simple wrapper of this core fucntion 
> __replace_domain_page.
> This way mm.c may be more readable.

Sounds great. Refactoring mm.c is good itself.
I have to admit that mm.c is unnecessarily complicated.
-- 
yamahata

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