Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Sep 1998 22:50:23 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        rminnich@Sarnoff.COM (Ron G. Minnich)
Cc:        hackers@FreeBSD.ORG
Subject:   Re: malloc()ing 64K physically contiguous buffer in kernel
Message-ID:  <199809212250.PAA20031@usr04.primenet.com>
In-Reply-To: <Pine.SUN.3.91.980921094533.25671B-100000@terra> from "Ron G. Minnich" at Sep 21, 98 09:50:40 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809212250.PAA20031>