From owner-freebsd-current Mon Mar 20 14:09:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA08455 for current-outgoing; Mon, 20 Mar 1995 14:09:27 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA08444 for ; Mon, 20 Mar 1995 14:09:24 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03201; Mon, 20 Mar 95 15:03:03 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503202203.AA03201@cs.weber.edu> Subject: Re: Why does kern_lkm.c use kmem_alloc()? To: davidg@Root.COM Date: Mon, 20 Mar 95 15:03:02 MST Cc: wollman@halloran-eldar.lcs.mit.edu, current@FreeBSD.org In-Reply-To: <199503202146.NAA02245@corbin.Root.COM> from "David Greenman" at Mar 20, 95 01:46:01 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > >> Can anybody explain why kern_lkm.c uses kmem_alloc() to allocate > >> memory rather than malloc()? Is it just because of the kernel > >> malloc()'s size limit? (I'd really like for it to use malloc so that > >> I could tell how much memory is occupied by LKMs from `vmstat -m'.) > > > >Contiguous driver buffer space for DMA target. > > Contiguous? You mean _physically_ contiguous memory? kmem_alloc() has never > tried to return that. Virtually, at least initially, so that the loader can load the code contiguously in the address space in which it is to run. Oh, and it wants to load the code page aligned. kmem_alloc returns memory statring at the start of a page (or at least it used to and does in NetBSD). This is actually a limitation in the linker with respect to allowable relocated code starts. The change of allocator was, I think, Chris D.'s doing when it was imported to NetBSD. He also remed the root restriction on listing of modules (as opposed to loading/unloading them) and wrote man pages. I had inlined the Sun man pages in the initial beta -- I think they were removed soon after I saw them. They were at the end of the load/unload/etc. utilities -- I was using a Sun as the developement environment and wanted 4.1.3 command line compatability. Really, the kernel memory needs two allocation directions (top-down, bottom-up) and it needs to allocate objects in one pool or the other based on it being high or low persistance. Allocating with the generic memory allocator, even if the page alignment problems are solved, is a sure invitation to trouble with fragged memory, especially in the case of reloads (modules really want a third pool type for medium persistance VM objects). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.