> 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.
I'm not saying I'm opposed to trying things that you suggest with RCU if you
think it's worth the effort. I was just pointing out my thoughts on the
matter and welcoming input.
Erik
|