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>