rmlock(9) two additions

[Max Laier]

On Tuesday 24 August 2010 16:02:34 Stephan Uphoff wrote:
> Yes - this is a problem that needs to be addressed.
> Fortunately most platforms won't need to be as strict and I suggest per
> platform parameters.
> An alternative that was in my original design was to use a bitmap for
> the rm_noreadtoken.
> Each CPU would then have an associated bit that will only be cleared by
> that cpu.
> This would also allow targeted IPIs to only the token holders.

Okay ... attached is a version with the bitmask idea.  It is not using a per 
platform parameters, yet.  But I believe it fixes the issue in general.  This 
comes at the cost of an additional memory reference to pc_cpumask on the exit 
conditional from the fast-path.  I don't think this is too much of a problem 
currently, as this will be in the cache already ... but I might be wrong.

For easier review, I've also attached my current version of kern_rmlock.c.

BTW, this also fixes the trylock race by trylocking the base lock.  Again, I 
don't think the race against other readers is a concern in the trylock API.

I'd like to move forward with this in some way ... any objections and/or input 
on what to do/fix before committing this?  Any ideas/pointers on how to best 
implement the per platform selector?

Thanks,
  Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rmlock.full.diff
Type: text/x-patch
Size: 13697 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20100826/1aa5fd8a/rmlock.full.bin