PoC: passive serialization

Mindaugas Rasiukevicius rmind at netbsd.org
Tue Jun 24 02:09:44 UTC 2014


Mateusz Guzik <mjguzik at gmail.com> wrote:
> Cursory look suggests passive serialization got very limited use in
> NetBSD, I was also unable to find any benchmarks.

We have been avoiding RCU-like synchronisation in favour of alternative
techniques.  Passive serialisation was added relatively recently.  Also,
in many cases we can get away with a simpler way to ensure the quiescent
state (c.f. xc_broadcast(9) calls will nullop in the NetBSD tree).

As for benchmarks: well, benchmarks of what?  The writer side?  It is very
expensive and slow.  However, this is exactly what passive serialisation
promises: extremely low cost on the reader side and very expensive writer
side.  The writer side can be improved by garbage collecting the items in
a batch (and NetBSD interface allows the caller to do that).  However, if
the reader-writer ratio is not significantly dominated by the readers and
the potential pressure on memory is not desirable, then you hit the limits
of passive serialisation.

At this point, if you are trying to address those limitations - you are
basically (re)implementing RCU.  At least, in a sense of heading towards
the area covered by its patent portfolio.  And that may be a bit tricky.

> I do understand and appreciate your cautious approach, but it also
> limits the potential.
> 
> Do you have any materials which would show gains of using the concept as
> implemented in your code? Right now it is unclear if the implementation
> limited to this patent can yield benefits which would justify added
> complexity.

I think you miss the point.  A lot of that machinery (three queues, extra
bitmasks, etc) is either redundant or could be done a simpler/better way.
It is there to implement the claims of the lapsed patent.  There are no
technical gains (quite the opposite).  The gain is the reduced risk.

It is up to you which approach do you want to take.  I am just suggesting
to put some thought on non-technical aspects of this problem as well.

-- 
Mindaugas


More information about the freebsd-arch mailing list