Date: Tue, 4 Feb 1997 15:41:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kish@browncow.com (Bill Kish) Cc: hackers@freefall.freebsd.org Subject: Re: kernel malloc options Message-ID: <199702042241.PAA13265@phaeton.artisoft.com> In-Reply-To: <199702031942.OAA18041@browncow.com> from "Bill Kish" at Feb 3, 97 02:42:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702042241.PAA13265>