[Port-solaris] Re: bozonlock
Andrew Deason
adeason@sinenomine.net
Sat, 12 Jul 2014 22:55:48 -0500
[Copying to openafs-devel, since this possibly not Solaris-specific.]
On Thu, 3 Jul 2014 22:15:54 +0000
Mark Vitale <mvitale@sinenomine.net> wrote:
> Some code comments (1) imply that bozonlock was originally intended
> for use in the Solaris port. However, sometime before IBM 1.0, it was
> specifically disabled for Solaris by the addition of #define
> AFS_NOBOZO_LOCK (2).
Specifically, the comments say it's for a Sun OS, and it was disabled
for SunOS 5 (i.e. Solaris). For pre-Solaris SunOS presumably it was
still active at the time, and that is what it was developed for.
I assumed it was created due to some shortcoming in the SunOS 4 apis,
which is why it is (or was) the only place we have a kind of recursive
lock.
> Does anyone know why bozonlock was disabled for Solaris? Does anyone
> know any reason why it could/should not be reinstated for Solaris?
Well, you have to have a conversation about why you'd want it turned on
in the first place to have a meaningful conversation about this. Without
a reason to turn it on, obviously it's preferable to not have it.
But otherwise:
It serializes all page-related code for a single vnode. I'm not looking
at the code right now, but I don't believe we otherwise would do that
without the pvnLock; that alone means it's an unnecessary overhead and
makes parallel reads and other such things possibly much slower.
It also always sounded to me like a platform-specific hack, and adding
platform-specific oddities and restrictions seems like it would make the
code more complex and harder to understand. (Of course, it's pretty
confusing having those calls in solaris-specific code when they're
always disabled, but they should probably just be removed from there.)
I assume it was taken out because the justification for it in the first
place was some limitation in SunOS 4. That restriction was lifted in
Solaris, and so the pvn lock stuff was removed, and replaced with
something more reasonable.
--
Andrew Deason
adeason@sinenomine.net