RE: [Xen-devel] [PATCH] Reduce overhead in find_domain_by_id() [0/2]

["Santos, Jose Renato G" <joserenato.santos@xxxxxx>]

Keir,

I have already removed the following from linux RCU code:
1) "bh" version of RCU functions, not needed in Xen since 
   sofirqs cannot preempt hypervisor
2) synchronization calls that block waiting for readers
   to complete. (we just need asyncronous call back)
3) support for hotplug CPUs (Xen does not support it).

Looking at the code again, the following could also be removed:
1) logic and functions associated with limiting the RCU batch size
   This is probably not needed since we do not expect a lot of RCU
   activity
2) Functions which are not  being used:
    2.1) rcu_batch_after
    2.2) rcu_needs_cpu
    2.3) rcu_batches_completed

Can't think of anything else. If you want I can remove these and submit
a revised patch.
It seems that there is not much more we could remove. Not sure if you
have something else in mind...

Regards

Renato
   
> -----Original Message-----
> From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx] 
> Sent: Wednesday, December 06, 2006 4:13 AM
> To: Apparao, Padmashree K; Keir Fraser; Santos, Jose Renato 
> G; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Turner, Yoshio; Jose Renato Santos; G John Janakiraman
> Subject: Re: [Xen-devel] [PATCH] Reduce overhead in 
> find_domain_by_id() [0/2]
> 
> 
> Okay, sounds good. I don't want the whole Linux RCU mechanism 
> in Xen particularly. Linux may well need the complexity 
> because it leans on RCU quite heavily these days, but Xen 
> will do so a whole lot less I'm sure and something much 
> simpler should suffice. I'll look into this -- the patches 
> you sent provide a good starting point, thanks!
> 
>  -- Keir
> 
> On 6/12/06 11:52, "Apparao, Padmashree K" 
> <padmashree.k.apparao@xxxxxxxxx>
> wrote:
> 
> > Keir,
> > 
> > Earlier this summer I had done some experiments with Iperf 
> and found 
> > that find_domain_id was consuming 7% of cpu while do_grant_table_op 
> > was consuming 10.5%. A quick fix to figure what the upper bound of 
> > performance gain was to remove the hash table lookups in 
> > find_domain_by_id and we saw a 12% improvement in perf receive 
> > performance.
> > The results of these finding were published in our paper at VTDC.
> > In that paper we also discuss how the inter vm 
> communication by grant 
> > tables was consuming a considerable amount of time and what 
> could be 
> > possibly done to optimize.
> > 
> > I will send the paper is a separate note to you and Renato.
> > 
> > Thanks
> > - Padma
> > 
> > 
> > 
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir 
> > Fraser
> > Sent: Wednesday, December 06, 2006 12:44 AM
> > To: Santos, Jose Renato G; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Cc: Yoshio Turner; Jose Renato Santos; G John Janakiraman
> > Subject: Re: [Xen-devel] [PATCH] Reduce overhead in 
> > find_domain_by_id() [0/2]
> > 
> > On 6/12/06 1:35 am, "Santos, Jose Renato G" 
> <joserenato.santos@xxxxxx>
> > wrote:
> > 
> >> 
> >> This is a set of patches to improve performance of
> > find_domain_by_id().
> >> find_domain_by_id shows up high in profiles for network 
> I/O intensive 
> >> workloads.
> >> Most of the cost for this function comes from 3 main functions (of 
> >> aproximate equal costs): 1)read_lock(), 2)read_unlock() and 
> >> 3)get_domain().
> >> These patches replace the lock used for accessing domain_list and 
> >> domain_hash with a lock free RCU scheme. Experiments 
> confirm that the 
> >> cost of find_domain_by_id() is in fact reduced by 2/3.
> >> The patches apply cleanly to changeset 12732.
> > 
> > Do you have numbers for performance improvement on a macro 
> benchmark?
> > 
> >  -- Keir
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
> 

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