From owner-freebsd-hackers Tue Nov 3 11:41:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27951 for freebsd-hackers-outgoing; Tue, 3 Nov 1998 11:41:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27943 for ; Tue, 3 Nov 1998 11:41:29 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA04914; Tue, 3 Nov 1998 12:41:13 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd004895; Tue Nov 3 12:41:08 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA03979; Tue, 3 Nov 1998 12:41:03 -0700 (MST) From: Terry Lambert Message-Id: <199811031941.MAA03979@usr05.primenet.com> Subject: Re: "panic: free: multiple frees" VM bug? (long) To: julian@whistle.com (Julian Elischer) Date: Tue, 3 Nov 1998 19:41:03 +0000 (GMT) Cc: dg@root.com, lile@stdio.com, hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Nov 2, 98 08:56:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I also doubt if you really want to free them either.. > > possibly keep a pool of them and recycle them in your own free list. Exactly what I was thinking, actually. The problem with allocating and freeing these things is that you could very easily fragment the KVA space to the point where subsequent contigalloc's will fail. FreeBSD can not (currently) relocate pages in physical memory in order to "defrag" the KPA (Kernel Physical Address) space, and thus most drivers that want a contiguous chunk of memory allocate the memory early on -- usually at device attach -- to ensure that the memory will actually be available when they later need it. Yes, it's theoretically possible to resolve these issues, but they haven't been resolved yet, so it's not safe to code as if they have. Even so, assuming these issues *were* resolved, you'd probably *still* want to keep a pool around to avoid the allocator overhead, which is not inconsiderable, and at worst if you insisted on trying to free as much memory back as possible instead of just swallowing it forever like everyone else does, you'd high/low watermark the usage to delay allocations and deallocations in the hopes that they would be unnecessary, on average. This is all more complicated than you should be working with in the current kernel environment for the amount of memory you are likely to be using at any one time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message