Re: [PATCH] RCU subscriber_list Process Notification (pnotify)

On Thu, Sep 29, 2005 at 01:09:16PM -0500, Erik Jacobson wrote:
> > Could you use a per-subscriber reference count ? That will allow
> > you to drop rcu_read_lock() safely.
> 
> In the performance tests, I showed that I really couldn't measure
> the speed difference in AIM7 and fork bomb tests using the original 
> rwsems and a kernel without pnotify and job.  The process for the tests and 
> any children processes all had two subscribers (keyring and job) at the 
> time.  I'm just not convinced that RCU is the right fit for pnotify in 
> general since I don't see a speed gain.  
> 
> If my proof of concept rcu pnotify patch is so bad that it can't even be
> used to gage some performance numbers, I'm happy to try new things.  
> However, it seems to me that most methods for fixing the rcu pnotify patch
> would decrease efficiency rather than increase it.
> 
> As was pointed out to me in a discussion in the pagg mailing list, we 
> could be in a situation where we normally have as many writers as
> readers for many situations.  I'm not sure the rule of thumb for writers vs 
> readers points to a good match for RCU.

Oh, I am only pointing out RCU problems. It does make sense to do
some benchmarking and see if it has benefits over rwsem or not.
I would like to see the comparison on one of those SGI behemoths
instead of a 2-cpu box :)

Thanks
Dipankar


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl