From owner-freebsd-current Sat Feb 23 13:55:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 0A2BE37B405; Sat, 23 Feb 2002 13:55:12 -0800 (PST) Received: from pool0164.cvx40-bradley.dialup.earthlink.net ([216.244.42.164] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ek8J-0004FU-00; Sat, 23 Feb 2002 13:55:07 -0800 Message-ID: <3C780FAF.F95A23EF@mindspring.com> Date: Sat, 23 Feb 2002 13:54:55 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Matthew Dillon , Seigo Tanimura , current@FreeBSD.ORG, John Baldwin Subject: Re: How to fix malloc. References: <200201051752.g05Hq3gG074525@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200201241022.g0OAMISM093913@faber.r.dl.itc.u-tokyo.ac.jp> <20020124024534.V13686@elvis.mu.org> <200202131739.g1DHdZT5023794@rina.r.dl.itc.u-tokyo.ac.jp> <200202190945.g1J9j9kg076110@rina.r.dl.itc.u-tokyo.ac.jp> <200202232051.g1NKpE741310@apollo.backplane.com> <20020223211449.GJ80761@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > All these per-subsystem free-lists are making me nervous in both > complexity and wasted code... Me too. > Ok, instead of keeping all these per-subsystem free-lists here's what > we do: > > In kern_malloc:free() right at the point of > if (size > MAXALLOCSAVE) we check if we have Giant or not. > if we do not then we simply queue the memory > however, if we do then we call into kmem_free with all the queued memory. > > This ought to solve the issue without making us keep all these > per-cpu caches. One modification: limit the number that are freed per invocation to some number small enough that there won't be a big latency. Once everything gets to this point, though, there will be nothing to trigger a free with giant held, and you'll just queue things up forever. Really, we need counted queues -- queues that know the number of elemenets on them. This is a requirement for RED-Queueing, and it will let us know when the queue gets deep... then you can grab giant, and flush down the queue if it hits a high watermark. Obviously, the correct way to handle this is per CPU memory pools that don't have any need for lock contention at all on the "real" frees. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message