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
|