From owner-freebsd-arch Thu Apr 11 4: 2:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 2FC3C37B400 for ; Thu, 11 Apr 2002 04:02:33 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g3BB2WQ28154 for ; Thu, 11 Apr 2002 04:02:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id D25C739EA; Thu, 11 Apr 2002 04:02:33 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Wes Peters Cc: Dag-Erling Smorgrav , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Removing limits from malloc(9) In-Reply-To: <3CB37FAF.DE67363E@softweyr.com> Date: Thu, 11 Apr 2002 04:02:33 -0700 From: Peter Wemm Message-Id: <20020411110233.D25C739EA@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wes Peters wrote: > Dag-Erling Smorgrav wrote: > > > > Jeff Roberson 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 contras t > > > 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. You know, at work the one and only time we ever check malloc limits is when we discover that a transient load spike caused it to hit some limit and it crashed or locked up as a result. When the machine crashes or deadlocks automatically as a result of hitting the limits, one has to wonder what the point is? It is crashing in order to protect us from what? crashing? Personally, I'd be happy with counts being done per-cpu (to avoid contention) and aggregated periodically (eg: at vmstat -m time). And to hell with the limits. But that's just me. :-) Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message