Date: Mon, 22 Jan 2001 18:15:23 -0500 From: "Bosko Milekic" <bmilekic@technokratis.com> To: "Dag-Erling Smorgrav" <des@ofug.org> Cc: <arch@FreeBSD.ORG> Subject: Re: Second zone allocator patch Message-ID: <008901c084c9$32485cf0$1f90c918@jehovah> References: <xzp3decp50i.fsf@flood.ping.uio.no> <015201c084aa$6c356800$1f90c918@jehovah> <xzpy9w3gqm1.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote:
> "Bosko Milekic" <bmilekic@technokratis.com> writes:
> > Dag-Erling Smorgrav wrote:
> > > - use atomic operations for updating the statistics counters.
> > Can you get away with grouping the changes to these counters while
> > holding the zlist lock? If so, you can get rid of the necessity for the
> > atomic() ops.
>
> Well, right now they're updated inside _zget(), which holds the zone
> lock, and the zlist lock shouldn't be held while holding the zone lock
> (it'll cause a lock order reversal if vm_zone_sysctl() runs at the
> same time). Are atomic operations too expensive? Since these are just
> statistics, can we get away with leaving them as they are, at the risk
> of getting incorrect stats once in a while?
Better be correct and use atomic*(), then.
[...]
> > > the Giant hackery in zinitna() and _zget().
>
> The Giant hackery was not committed, btw - Jason objected. Since the
> zone allocator still runs under Giant anyway, it shouldn't matter yet.
What Giant hackery is this? If this is the KASSERT, that's not "hackery,"
it's a debugging and prevention aid.
> DES
> --
> Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008901c084c9$32485cf0$1f90c918>