Date: Tue, 09 Apr 2002 17:56:31 -0600 From: Wes Peters <wes@softweyr.com> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Jeff Roberson <jroberson@chesapeake.net>, arch@freebsd.org Subject: Re: Removing limits from malloc(9) Message-ID: <3CB37FAF.DE67363E@softweyr.com> References: <20020408041726.U53877-100000@mail.chesapeake.net> <xzplmbyr3a7.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote:
>
> Jeff Roberson <jroberson@chesapeake.net> writes:
> > The last bit that is missing before we can call malloc/free w/o Giant is
> > the malloc_type statistics. Currently there is nothing really protecting
> > them. There really is no lock that they can conveniently live under. I
> > have a few options. The one that I'm leaning towards is only enabling
> > malloc_type statistics if INVARIANTS is compiled in. Then I could make
> > one lock per malloc_type. The reason this shouldn't be the default is
> > because it creates a single point of contention which is in sharp contrast
> > with the rest of the allocator.
>
> It's still a lot better than Giant, and it's a leaf lock so there
> shouldn't be any worries about reversal. I'd go for it if I were you.
Can they be updated with an atomic increment? For statistics like this,
being off by 1 or 2 on read isn't so important as long as you don't miss
a bunch of counts.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?3CB37FAF.DE67363E>