On 03/11/2011 06:09 AM, Russell Bryant wrote: > On Thu, Mar 10, 2011 at 12:04 AM, Steven Dake <[email protected]> wrote: >> Another interesting idea that may be useful for a second patch is to >> keep a list of freed frames to avoid the malloc/free overhead for the >> common cases of totemsrp. Surprisingly this is quite a significant >> amount of overhead (according to oprofile). > > This is definitely good assuming only one thread is going to mess > around with the free list. Is that the case here? If you have to add > locking, it's even worse. One thing I have done before in that case > is create a free list per-thread using thread local storage. >
tls may be a good choice here. I am not 100% certain the upcalls from poll (which can result in free operations) are mutually excluded from downcalls via totempg_mcast (which doees an alloc). In fact I think I tried this exact free list idea previously and had failures requiring a specific mutex for the free list. I wonder if this could be the cause of: https://bugzilla.redhat.com/show_bug.cgi?id=490856 https://bugzilla.redhat.com/show_bug.cgi?id=617644 In Corosync 2.0, we remove almost entirely threads from the implementation, but this could be a problem for third party apps that use the totempg DSO directly. > -- > Russell Bryant > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
