From owner-freebsd-hackers Mon Sep 21 15:51:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA02418 for freebsd-hackers-outgoing; Mon, 21 Sep 1998 15:51:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02342 for ; Mon, 21 Sep 1998 15:51:14 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA06261; Mon, 21 Sep 1998 15:50:33 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd006222; Mon Sep 21 15:50:24 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA20031; Mon, 21 Sep 1998 15:50:23 -0700 (MST) From: Terry Lambert Message-Id: <199809212250.PAA20031@usr04.primenet.com> Subject: Re: malloc()ing 64K physically contiguous buffer in kernel To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Mon, 21 Sep 1998 22:50:23 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Ron G. Minnich" at Sep 21, 98 09:50:40 am 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 > FWIW, the whole issue of mallocing physically contiguous memory also came > up as a sore point at the Extreme Linux workshop. People need to be able > to allocate physically contiguous memory long after boot time, not just in > that small window of time where lots of contig memory is available. > Nobody, nobody, nobody has a decent answer. NT has the least indecent > answer at the moment, so people seem to think it's good :-( The kernel VM space's physical pages are relocatable; that's the point of having a kernel virtual address space. Because the kernel is monolithically loaded, and because such an interface will never *not* be part of the minimal memory footprint, it seems to me that you could easily build a KVA space defragmenter in order to achieve sufficient contiguois memory to do the job, so long as that defragmenter was part of the initial (non-fragmented) kernel image load. For the future, when the kernel will be sectionally discarable, as drivers are placed in seperate ELF sections, there will need to be a section attribute to allow for marking the relocation code as non-relocatable (similar to the previously discussed marking of the code in the swap-path as non-swappable, and allowing the majority of the kernel to be swapped out, as necessary, to increase cache efficiency, or the marking of probe code as "discard after run", etc.). 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