Date: Wed, 10 Apr 2002 05:18:44 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Wes Peters <wes@softweyr.com> Cc: Dag-Erling Smorgrav <des@ofug.org>, <arch@freebsd.org> Subject: Re: Removing limits from malloc(9) Message-ID: <20020410051245.A87494-100000@mail.chesapeake.net> In-Reply-To: <3CB37FAF.DE67363E@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Apr 2002, Wes Peters wrote: > Dag-Erling Smorgrav wrote: > > > > 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. > An atomic increment would still cause cache thrashing. I considered doing per cpu queues for the statistics and then aggregating them when someone wants to report them. This doesn't work if you want to do limits though, since you'd need to check all of the statistics caches at each call. I suppose that this is really good enough at this point. Maybe when we're running on 64 or 128 CPU systems the cache thrashing will hurt enough to get rid of limits. :-) Until then I'll just leave them the way they are and wrap the whole thing in a per malloc_type mutex. This should sufficiently reduce contention and make malloc(9) totally mp safe. Jeff 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?20020410051245.A87494-100000>