From owner-freebsd-hackers Tue Feb 4 14:44:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA19380 for hackers-outgoing; Tue, 4 Feb 1997 14:44:34 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA19375 for ; Tue, 4 Feb 1997 14:44:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA13265; Tue, 4 Feb 1997 15:41:33 -0700 From: Terry Lambert Message-Id: <199702042241.PAA13265@phaeton.artisoft.com> Subject: Re: kernel malloc options To: kish@browncow.com (Bill Kish) Date: Tue, 4 Feb 1997 15:41:33 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <199702031942.OAA18041@browncow.com> from "Bill Kish" at Feb 3, 97 02:42:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Currently, I'm malloc()ing these structures as needed using the > following parameters: > > malloc((u_long)sizeof(*conxn), M_TEMP, M_NOWAIT) > > This appears to work fine in my initial lightly loaded tests, > however, I'm concerned about what will happen when the system is under > heavy load. I have the following questions and would appreciate any > advice offered! > > 1) Is malloc() a reasonable allocator for small highly dynamic > objects? No. Establish a freelist. > 2) Is M_TEMP a good choice? Does it make a difference? Not if there is a high turnover, or sporadic growth/decline in usage over a short time. You should establish a new pool ID; probably, we should establish a mechanism for allocating pools, and preallocate the ones with mainifest constants to match the constants, and then let users deal with them from there (ie: you would not be guaranteed initialization order, so you would have to code your stuff to use an integer instead of a constant, and eat whatever overhead that caused). > 3) Are there any config options that affect the amount of pinned > kernel memory available for malloc? The system will be doing > little else besides dealing with these packets... John or David would have to answer this... I believe, though, that the kernel address space is fixed. The amount of pinned memory would depend on the physical backing stor, and how much fragmentation exists at the time you ask (I think). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.