From owner-freebsd-platforms Fri Nov 29 20:40:43 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA23161 for platforms-outgoing; Fri, 29 Nov 1996 20:40:43 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA23156 for ; Fri, 29 Nov 1996 20:40:41 -0800 (PST) Received: from imp by rover.village.org with local (Exim 0.56 #1) id E0vThEF-0002fP-00; Fri, 29 Nov 1996 21:40:39 -0700 To: platforms@freebsd.org Subject: FreeBSD/MIPS anybody Message-Id: From: Warner Losh Date: Fri, 29 Nov 1996 21:40:39 -0700 Sender: owner-platforms@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Are there people other than myself that are interested in getting FreeBSD running on MIPS machines? They made a bunch of different ones: DECstations, ARC BIOS PCs, SGI boxes, old pre SGI-MIPS hardware, Sony's NEWS and likely a dozen others that I've not been able to recall. I have an ARC BIOS MIPS PC that I'd love to have FreeBSD running on, but don't really want to do the MIPS port by myself. Anybody else out there with disk space to burn, and old MIPS hardware? Warner From owner-freebsd-platforms Fri Nov 29 21:46:59 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA25227 for platforms-outgoing; Fri, 29 Nov 1996 21:46:59 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA25222; Fri, 29 Nov 1996 21:46:56 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA25227; Sat, 30 Nov 1996 16:16:47 +1030 (CST) From: Michael Smith Message-Id: <199611300546.QAA25227@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD/MIPS anybody In-Reply-To: from Warner Losh at "Nov 29, 96 09:40:39 pm" To: imp@village.org (Warner Losh) Date: Sat, 30 Nov 1996 16:16:46 +1030 (CST) Cc: platforms@FreeBSD.org, dyson@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh stands accused of saying: > Are there people other than myself that are interested in getting FreeBSD > running on MIPS machines? They made a bunch of different ones: DECstations, > ARC BIOS PCs, SGI boxes, old pre SGI-MIPS hardware, Sony's NEWS and likely > a dozen others that I've not been able to recall. I have an ARC BIOS MIPS > PC that I'd love to have FreeBSD running on, but don't really want to do > the MIPS port by myself. Anybody else out there with disk space to burn, > and old MIPS hardware? You know about me already, so this is just for general reference; I have a couple of old Mips (BE) systems and documentation of varying degrees and an IPC if the FreeBSD-sparc people are interested. What strikes me as the biggest real problem is the highly x86-optimised VM, and along with that perhaps the blurring of MI/MD code in the FreeBSD kernel. I've been studying the NetBSD code for a little while now, and it strikes me just how much of the VM seems to be replicated from one architecture to the next. Is this really necessary? How much of the FreeBSD VM is actually x86-specific, and how much could reasonably be moved out and reused by other architectures? > Warner -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-platforms Fri Nov 29 22:12:59 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26270 for platforms-outgoing; Fri, 29 Nov 1996 22:12:59 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA26265; Fri, 29 Nov 1996 22:12:55 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id BAA09955; Sat, 30 Nov 1996 01:12:40 -0500 (EST) From: "John S. Dyson" Message-Id: <199611300612.BAA09955@dyson.iquest.net> Subject: Re: FreeBSD/MIPS anybody To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sat, 30 Nov 1996 01:12:36 -0500 (EST) Cc: imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org In-Reply-To: <199611300546.QAA25227@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 30, 96 04:16:46 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > What strikes me as the biggest real problem is the highly > x86-optimised VM, and along with that perhaps the blurring of MI/MD > code in the FreeBSD kernel. > The FreeBSD VM code uses the SAME assumptions as the original Lite & Lite/2 code except we have removed some broken-ness like pagemove :-). I hope that those concerns about machine dependence are not due to disinformation from others. There might have to be some mods and enhancements to do a port to a given architecture, but the end result will be vastly superior to the original Lite & Lite/2 code that others are currently using. (Note that the original Lite code doesn't do a credible job of working on a heavily loaded system, and it has numerous bugs-- so, frankly, I am not sure that it is properly ported to any machine.) > > I've been studying the NetBSD code for a little while now, and it > strikes me just how much of the VM seems to be replicated from one > architecture to the next. Is this really necessary? How much of > the FreeBSD VM is actually x86-specific, and how much could > reasonably be moved out and reused by other architectures? > The only thing that is substantially X86 specific is the pmap code. When working on the VM code, one has to understand it... Otherwise one gets weird crashes with even the simplest changes. I don't think that very many individuals understand all of the code above the pmap layer. I do think that problems with previous port attempts are due to a lack of understanding of how the code works. The code is subtile^2. There are some X86 optimizations, but those are implemented mostly in the pmap code. Those routines should be noops on architectures like R4000, where they have software managed TLB's. We don't really need the reference bit, and our performance will degrade under heavy load without it. But, NO OS is going to do as well without that bit. The X86 specific optimizations (as opposed to pmap re-design) only account for a small part of the FreeBSD performance gains. John From owner-freebsd-platforms Sat Nov 30 01:17:02 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA01856 for platforms-outgoing; Sat, 30 Nov 1996 01:17:02 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA01851; Sat, 30 Nov 1996 01:16:57 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id TAA25734; Sat, 30 Nov 1996 19:46:39 +1030 (CST) From: Michael Smith Message-Id: <199611300916.TAA25734@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD/MIPS anybody In-Reply-To: <199611300612.BAA09955@dyson.iquest.net> from "John S. Dyson" at "Nov 30, 96 01:12:36 am" To: toor@dyson.iquest.net (John S. Dyson) Date: Sat, 30 Nov 1996 19:46:38 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk John S. Dyson stands accused of saying: > > > > What strikes me as the biggest real problem is the highly > > x86-optimised VM, and along with that perhaps the blurring of MI/MD > > code in the FreeBSD kernel. > > > The FreeBSD VM code uses the SAME assumptions as the original > Lite & Lite/2 code except we have removed some broken-ness like > pagemove :-). I hope that those concerns about machine dependence > are not due to disinformation from others. There might > have to be some mods and enhancements to do a port to a given > architecture, but the end result will be vastly superior to the > original Lite & Lite/2 code that others are currently using. I'm not sure whether it's disinformation, or just lack of more accurate information 8) Still, you'd have to admit that the pmap module is big and dark and scary to your average hacker 8( > When working on the VM code, one has to understand it... Otherwise This is an understatement of the first order 8) and the problem that I was trying to get at; there's a significant body of processor-dependant code tied to the VM required for any port, and for FreeBSD, this code is sufficiently different I couldn't, for example, take a pmap/locore from an old BSD port to the Sony NEWS and use it (even modulo hardware changes) on my Mipsco boxes for FreeBSD. Of course, if I'm wrong and it's actually totally trivial, then I'll just go sit in the corner and cry 8) Any chance of a pmap(9) manpage detailing its features and requirements? 8) > John -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-platforms Sat Nov 30 06:57:46 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA19472 for platforms-outgoing; Sat, 30 Nov 1996 06:57:46 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA19464; Sat, 30 Nov 1996 06:57:43 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id JAA10579; Sat, 30 Nov 1996 09:57:23 -0500 (EST) From: "John S. Dyson" Message-Id: <199611301457.JAA10579@dyson.iquest.net> Subject: Re: FreeBSD/MIPS anybody To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sat, 30 Nov 1996 09:57:18 -0500 (EST) Cc: toor@dyson.iquest.net, msmith@atrad.adelaide.edu.au, imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org In-Reply-To: <199611300916.TAA25734@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 30, 96 07:46:38 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > This is an understatement of the first order 8) and the problem that I > was trying to get at; there's a significant body of > processor-dependant code tied to the VM required for any port, and for > FreeBSD, this code is sufficiently different I couldn't, for example, > take a pmap/locore from an old BSD port to the Sony NEWS and use it > (even modulo hardware changes) on my Mipsco boxes for FreeBSD. > > Of course, if I'm wrong and it's actually totally trivial, then I'll > just go sit in the corner and cry 8) Any chance of a pmap(9) manpage > detailing its features and requirements? 8) > I have problems even making trivial mods to the pmap code, and being successful. One problem is that wrong-ness in the code doesn't always break things immediately. I suspect that given a new architecture just to get it barely running, the pmap mod would be approx as complex as two or three typical drivers (just a wild estimate.) In the pmap code, one needs to understand precisely what it needs to do (both the machine and the VM code.) For example, Bill Jolitz, writing the pmap code for the 386, apparently copied the hp code. I started a VM doc, but lost it in a disk crash. I might be able to start one again, but it would be a week or so at least to write (to complete.) Can't promise anything in the next week or so though, as bugs like the MSDOS problem appear regularly. John From owner-freebsd-platforms Sat Nov 30 07:40:16 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA22093 for platforms-outgoing; Sat, 30 Nov 1996 07:40:16 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA22082; Sat, 30 Nov 1996 07:40:13 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id KAA10646; Sat, 30 Nov 1996 10:39:46 -0500 (EST) From: "John S. Dyson" Message-Id: <199611301539.KAA10646@dyson.iquest.net> Subject: Re: FreeBSD/MIPS anybody To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sat, 30 Nov 1996 10:39:45 -0500 (EST) Cc: toor@dyson.iquest.net, msmith@atrad.adelaide.edu.au, imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org In-Reply-To: <199611300916.TAA25734@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 30, 96 07:46:38 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Of course, if I'm wrong and it's actually totally trivial, then I'll > just go sit in the corner and cry 8) Any chance of a pmap(9) manpage > detailing its features and requirements? 8) > PS, I FULLY intend to document the VM system. The more noise that is made about it, the higher priority it becomes. I am sure that if everyone said: I don't care about LFS for now, etc -- then I would be very willing to do the docs... Frankly, I am not in a programming mood right now, so it might not be a bad thing. Perhaps if DG and I produced more docs, then we could get more parallel efforts going. Actually, there are other kernel hackers that appear to be coming up to speed quite nicely (which is really a wonderful thing.) Maybe we can get the ball rolling!!! John From owner-freebsd-platforms Sat Nov 30 08:14:42 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA23877 for platforms-outgoing; Sat, 30 Nov 1996 08:14:42 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA23868; Sat, 30 Nov 1996 08:14:39 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vTs1l-0003wgC; Sat, 30 Nov 96 08:12 PST Received: from critter.tfs.com (localhost.dk.tfs.com [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id RAA05736; Sat, 30 Nov 1996 17:13:54 +0100 (MET) To: "John S. Dyson" cc: msmith@atrad.adelaide.edu.au (Michael Smith), imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org Subject: Re: FreeBSD/MIPS anybody In-reply-to: Your message of "Sat, 30 Nov 1996 09:57:18 EST." <199611301457.JAA10579@dyson.iquest.net> Date: Sat, 30 Nov 1996 17:13:53 +0100 Message-ID: <5734.849370433@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >I started a VM doc, but lost it in a disk crash. I might be able >to start one again, but it would be a week or so at least to >write (to complete.) Can't promise anything in the next week >or so though, as bugs like the MSDOS problem appear regularly. Would this by any chance be a help ? Poul-Henning Return-Path: toor@dyson.iquest.net From: "John S. Dyson" Message-Id: <199606170513.AAA07241@dyson.iquest.net> Subject: Re: cvs commit: src/sys/vm pmap.h vm_page.c vm_pageout.c src/sys/i386/i386 pmap.c To: phk@freebsd.org (Poul-Henning Kamp) Date: Mon, 17 Jun 1996 00:13:10 -0500 (EST) > > > 5) The pmap code has been sorely in need of re-organization, and I > > have taken a first (of probably many) steps. Please tell me > > if you have any ideas. > > Since this is some of the first code to become a roadblock for a different > architecture, and since our VM system is unique (in the most positive > meaning of the word): Stick a comment before each function called from > the arch-independent VM system and explain what the interface is and what > the code shall do. > I don't disagree, and have been thinking about it. I have some info, also (a first cut at some vm system docs). This is FYI, and remember that my language skills are very very poor, also this is not fully up to date now: Here is a very rough description of the FreeBSD MACH-based VM system internals... This document is not definitive, but meant as a quick reference or overview. The source code is currently the ONLY definitive documentation. If there is enough positive feedback from this document, I might be motivated enough to fill this in with more detail. Routines or symbols that will probably be supported forever in one way or another have a "SUPPORTED" notation. Those routines that could be at risk sometime in the future have no such notation. Definitions: Data Structure Equivalent vm_map ............... Address space vm_map_entry ......... Portion of address space pointing to only one vm_object or another vm_map vm_object ............ Repository for data vm_page .............. Indivisible amount of data pmap ................. Physical representation of Address space (Note that the names above, with "_t" appended refer to pointers as opposed to the structure itself... e.g. vm_map_t is a pointer to a struct vm_map.) Terminology Equivalent pager ................ A sort-of class that is described by information in the vm_object and the type of access to external data vnode_pager .......... Code in the vm system that knows how to do paging I/O with filesystem files. swap_pager ........... Code in the vm system that knows how to do paging I/O with swap partitions and files. Anonymous data in the system (e.g. bss) is paged using this. default_pager ........ A logical "placeholder" pager that takes few system resources until paging is needed. The default_pager is currently used only for vm_object's that might need to be paged using the swap_pager. When pageouts are needed, objects that are marked "default" are converted to "swap" with the associated allocation of swap data structures. device_pager ......... Code in the vm system that can provide memory mapped I/O with memory mapped devices. Most common use of this is X-Windows. kva .................. Kernel virtual address, usually of type vm_offset_t or caddr_t. sva,eva,va ........... Virtual address(s). sva - start virtual address, eva - end virtual address. pa ................... Physical address. m,p .................. Usually used for vm_page_t. offset ............... Offsets into objects are usually vm_ooffset_t, >>>> ^^^^^^^^^^^^ which translates into a long long. wired ................ Not pageable. clean ................ (As in "the page is clean"), means it is in sync with the backing store. Useful "handles" describing address spaces: (warning -- in the most general case, you should make sure that there is a "curproc"!!!). If your code is being called from a system call or I/O initiation routine, you should be safe. Current process address space (vm_map_t): (SUPPORTED) &curproc->p_vmspace->vm_map Current process pmap (pmap_t): (SUPPORTED) &curproc->p_vmspace->vm_pmap Kernel address space (vm_map_t): (SUPPORTED) kernel_map Kernel pmap (pmap_t): (SUPPORTED) kernel_pmap, (best referred to as vm_map_pmap(kernel_map)) Less commonly used "handles": Address spaces (submaps of kernel_map, unless noted otherwise): never checked for modification: clean_map buffer cache: buffer_map (submap of clean_map) pager and cluster buffers: pager_map (submap of clean_map) used for bounce buffers: io_map (submap of clean_map) malloc and mbuf cluster area: kmem_map mbuf clusters: mb_map (submap of kmem_map) args during exec: exec_map temporary mapping of exec hdr: exech_map UPAGES per process: upage_map Important macros: pa = VM_PAGE_TO_PHYS(m); (SUPPORTED) returns the physical address for a vm_page_t. m = PHYS_TO_VM_PAGE(pa); returns the vm_page_t associated with a physical address. (try to avoid PHYS_TO_VM_PAGE -- it doesn't always work, because not every physical address has a page, and it usually implies a design flaw, or a quick work-around that needs to be corrected in the future.) PAGE_WAKEUP(m); (SUPPORTED) This is used to free the lock on a page as represented by the PG_BUSY bit. Other processes that are waiting on that page are waken up. In order to wait on a page the following could be done: s = splhigh(); while ((m->flags & PG_BUSY) || m->busy) { m->flags |= PG_WANTED; tsleep(m, PVM, "xxxxxx", 0); } splx(s); >>>> should a macro be made for this ? ^^^^^ You would do that normally after a vm_page_lookup. VM_WAIT; (SUPPORTED) Use this if you have tried to do a vm_page_alloc in non-interrupt state. This blocks your process and wakes up the pageout daemon. When this returns, there likely will have some memory, so vm_page_alloc can be retried. Likely return values from most of the vm routines : KERN_SUCCESS, KERN_INVALID_ADDRESS, KERN_PROTECTION_FAILURE, KERN_NO_SPACE, KERN_INVALID_ARGUMENT, KERN_FAILURE, KERN_RESOURCE_SHORTAGE, KERN_NOT_RECEIVER?, KERN_NO_ACCESS? Important X86 tidbit: The kernel_pmap is always effectively mapped into the user's pmap. When referring to kernel space, one should use the kernel_pmap, and all processes will see the change in the kernel. Memory queues: vm_page_queue_free -- free pages vm_page_queue_zero -- free pages that are zero vm_page_queue_cache -- free pages that still have info may NOT be BUSY or mapped. vm_page_queue_active -- active pages vm_page_queue_inactive -- inactive pages Commonly needed VM system routines: int vm_map_find(map, object, offset, addr, length, find_space, prot, max, cow); (SUPPORTED) This finds AND allocates virtual space from the specified map (Address space). The user can optionally specify a vm object to map into the space (e.g. mapped file.) The parameters associated with the address space include: map -- The specific vm_map_t involved with the op addr -- Ptr to the address in the vm_map length -- Length of the mapping in bytes Note that the address (addr) above is equivalent to the address in a process or in the kernel. If the address is >= VM_MIN_KERNEL_ADDRESS you MUST use kernel_map, and not &curproc->p_vmspace->vm_map!!! Secondary note, unless you *really* know what you are doing, do not do a vm_map_find in the kernel map. Please use kmem_alloc instead. If you specify an initial value for addr, and find_space is zero, then the allocation request will succeed only if there is enough memory available at the specified address. The parameters associated with the vm object: object -- Optional VM object -- if NULL, a default pager object will be created as needed offset -- Offset into the object (long long, vm_ooffset_t) Additional parameters modifying the operation of the routine: find_space -- If there is no space at 'addr', space is found after that place. prot,max -- R/W permissions to address space: VM_PROT_READ, VM_PROT_WRITE, VM_PROT_EXEC cow -- Copy-on-write, original obj is NOT modified. Error returns: KERN_SUCCESS -- Operation completed KERN_INVALID_ADDRESS -- Address specified is invalid KERN_NO_SPACE -- No space in the map int vm_map_remove(map, start, end); (SUPPORTED) This routine deallocates the virtual space between start and end. All objects that are backing this space are deallocated as appropriate. This is sort-of inverse of vm_map_find above. Always returns KERN_SUCCESS. int vm_map_protect(map, start, end, new_prot, set_max); (SUPPORTED) Changes the access permissions for a virtual address range in the specified map. This routine makes all necessary modfications to the pmap associated with the map also. int vm_map_pageable(map, start, end, new_pageable); (SUPPORTED) Allows sections of a map to be wired or unwired into memory. int vm_map_check_protection(map, start, end, protection); int vm_map_lookup(map, addr, fault_type, out_entry, object, pindex, out_prot, wired, single_use); vm_page_t vm_page_alloc(object, pindex, flags); (SUPPORTED) flags -- VM_ALLOC_NORMAL normal process allocation VM_ALLOC_SYSTEM preferential allocation VM_ALLOC_INTERRUPT allocate interrupt-safely VM_ALLOC_ZERO normal process with priority to zero pages NON-BLOCKING. This is the lowest level page allocation routine. A NULL is returned if the allocation cannot be currently satisified. The pages are returned to the user with the PG_BUSY bit set and are not on any queue. After allocating the page, it is a good idea to issue a PAGE_WAKEUP(m) on the page, and at least wire the page. void vm_page_free(object, pindex); (SUPPORTED) This is the lowest level page free routine. This routine does NOT remove ANY mappings associated with the page. Chaos will ensue if the page is not properly removed from all pmap's. A normally used page can be removed from all pmap's by a vm_page_protect(m,VM_PROT_NONE); However, kernel mappings must be removed one-by-one. void vm_page_activate(m); void vm_page_deactivate(m); void vm_page_cache(m); void vm_page_wire(m); (SUPPORTED) NON-BLOCKING. These are the queue manipulation routines. These are used to affect the policy of the paging and allocation system. If a page is activated, it is not likely to be freed soon. If it is deactivated, it will more likely be used. Cached pages are similar to freed pages, available for allocation, but still have their identity for quick reuse. If a page is not in one of the other states for a long time, it is best to wire it so the system can at least account for it. A page that is wired is "hidden" from the pageout daemon. vm_object_t vm_object_allocate(type, size); type -- OBJT_DEFAULT, default -- converts to swap OBJT_VNODE, vnode object OBJT_SWAP, swap object OBJT_DEVICE, device object This is the routine that creates an object. The user should only normally create objects of type OBJT_DEFAULT. Note that the size is in units of pages. vm_object_t vm_pager_allocate(type, handle, size, prot, foff); (SUPPORTED) type -- OBJT_DEFAULT, default -- converts to swap OBJT_VNODE, vnode object OBJT_SWAP, swap object OBJT_DEVICE, device object This is the routine that creates an object and associates the object with a file. If the object already exists, the reference count for the object will be incremented. In the case of a vnode object, the handle is the vnode pointer, and the foff and prot are both ignored. In the case of a swap object the handle is a unique 32bit number (probably address), and the foff and prot are both ignored. The handle for a device object is likely the device vnode, the prot is the protection that the memory device can support, and the foff is the offset into the device. vm_object_deallocate(object); (SUPPORTED) This routine decrements the reference bit for the object, potentially freeing it. vm_page_protect(m, prot); (SUPPORTED) Used to turn off permissions for pages mapped into processes. vm_page_protect(m, VM_PROT_READ) helps implement COW, and vm_page_protect(m, VM_PROT_NONE) is an important step in freeing pages. vm_fault(map, vaddr, fault_type, change_wiring); (SUPPORTED) Does the things necessary to bring a page into a processes address space. The most common use of this routine is in the trap code to implement demand-paging. Most normal driver or system use would be as follows: vm_fault(map, vaddr, VM_PROT_READ or (VM_PROT_READ|VM_PROT_WRITE), 0); KMEM series of operations (meant to be used on kernel_map or submaps of kernel_map), they always return page aligned addresses. kva = kmem_alloc(map, size); kva = kmem_alloc_pageable(map, size); (SUPPORTED) kmem_alloc and kmem_alloc_pageable each allocate space from the kernel_map (or any of it's submaps except kmem_map). If memory is being allocated (instead of just virtual space), you should generally use kmem_alloc. kmem_alloc_pageable does not do all of the correct things in all cases for the setup of the underlying kernel_object offset. It is best to use kmem_alloc_pageable when you plug the pages directly into the kernel address space. kmem_free(map,addr,size); (SUPPORTED) Use kmem_free to give back the kernel address space as allocated by kmem_alloc or kmem_malloc. Be careful to remove any mappings specifically created by pmap_enter before freeing the address range. kva = kmem_malloc(map, size, waitflag); Use this special form of kmem_alloc for kmem_map or mb_map. Except for current usage, it is best not to use kmem_malloc in new kernel extensions. It is best to use malloc/free for things that you CAN use kmem_malloc for. MALLOC/FREE (refer to /sys/sys/malloc.h for available types.) These return aligned memory, but not necessarily on 1 page boundaries. kva = malloc(size, type, flags); (SUPPORTED) flags = M_NOWAIT (call like this from interrupt level.) = M_KERNEL (preferential allocation of memory.) = M_WAITOK (normal call for non-interrupt level.) malloc is callable using M_NOWAIT from both splbio and splimp interrupt levels. (void) free(kva, type); (SUPPORTED) The kva specified to free must be identical to the one returned by malloc. The type likewise should be the same, otherwise malloc usage accounting will not work correctly. >>>> more like "..., otherwise the system panics." PMAP routines. These routines are the lowest level defined interface to the processor memory management hardware. Given the virtual addresses have been set-up correctly, pmap can be kernel_pmap, the current processes' pmap or in some cases, another processes pmap. void pmap_enter(pmap, va, pa, prot, wired); (SUPPORTED) map a single page into the physical address space. void pmap_remove(pmap, sva, eva); (SUPPORTED) remove a range of pages from the physical address space. pa = pmap_extract(pmap, va); (SUPPORTED) get the physical address associated with the specified mapped page. pa = pmap_kextract(pmap, va); (SUPPORTED) same as pmap_extract, except is much more efficient and works only for the kernel_pmap. >>>> or submaps ? why else pmap arg ? va = pmap_map(va, startp, endp, prot); (SUPPORTED) map a contiguous range of pages from physical address startp through endp at virtual address va. The returned address points to the next address that can be used for mapping. pmap_protect(pmap, sva, eva, prot); (SUPPORTED) Removes permissions from page protections on pages in the specified range. It does NOT remove protections for other pmaps on the pages. pmap_qenter(va, m, count); pmap_qremove(va, count); (PROBABLY SUPPORTED) pmap_qenter/pmap_qremove are used for fast kernel mappings of vm_page's allocated from the VM system. The implied pmap is kernel_pmap, and must refer to va's that are >= VM_MIN_KERNEL_ADDRESS. Usually one would use address that were returned by kmem_alloc_pageable. The second argument to pmap_qenter is a pointer to an array of pages. This is used often in the buffer cache code for quick mapping of vm_page_t's. pmap_kenter(va, pa); pmap_kremove(va); (PROBABLY SUPPORTED) pmap_kenter/pmap_kremove are used for fast kernel mappings. The implied pmap is kernel_pmap and must refer to va's that are >= VM_MIN_KERNEL_ADDRESS. Usually one would use address that were returned by kmem_alloc_pageable. pmap_growkernel(topaddr); This routine supports the creation of additional pagetable pages to encompass the address "topaddr". Kind-of the equiv of sbrk for the kernel. FreeBSD does not need to preallocate all of the needed kernel pagetables up-front because of this routine. pmap_destroy(pmap); Decrements pmap ref-count, and if zero, destroy's it. pmap_reference(pmap); Increments pmap ref-count. pmap_pinit(pmap) Creates a pmap. pmap_object_init_pt(pmap, addr, object, pindex, size); Prefaults pages into a processes pmap. If the pages are in memory, they are placed directly into a processes address space. This is called at mmap time. pmap_prefault(pmap, addra, entry, object); Prefaults pages into a processes pmap. This only places pages that are in a region around the specified address. This is called at vm_fault time. pmap_change_wiring(pmap, va, wired); This notates the page as being wired. This DOES NOT actually wire the page. pmap_copy(dst_pmap, src_pmap, dst_addr, len, src_addr); This is a routine that might be used to short-circuit faulting pages into an address space from another. It is currently NOT used. pmap_zero_page(dstpa); (SUPPORTED) This is the routine that is used to zero a page for demand zero. pmap_copy_page(srcpa,dstpa); (SUPPORTED) This is the routine that is used to copy a page for COW. pmap_pageable(pmap, sva, eva, pageable); This notates a range of pages as being pageable and is information. It is currently NOT used. pmap_page_protect(dstpa, prot); Decreases the protection for a given page. It is used to remove a page from all address spaces (for example, prior to being freed), or to write-protect (for example, for setting up an address space for COW.) This routine should not normally be used, vm_page_protect is vastly superior. The pte bit routines below are much more complicated than they appear, because they have to check the pte's for each page in every pmap that the page is mapped. pmap_is_referenced(srcpa); (SUPPORTED) Senses the reference bit on a given page. pmap_is_modified(srcpa); (SUPPORTED) Senses the modified bit on a given page. pmap_clear_modify(dstpa); (SUPPORTED) Clears the modified bit for a given page. pmap_clear_reference(dstpa); (SUPPORTED) Clears the reference bit for a given page. kva = pmap_mapdev(pa, size); (SUPPORTED) Maps device memory into the kernel. kva space is allocated, and the physical device is mapped directly into the kernel_pmap ptes. This allows full memory access to the device from the kernel. Additional miscellaneous routines that are useful to kernel developers, but refer to them in the source. They most likely will be around for a "long time." vmspace_alloc(min, max, pageable); vmspace_free(vm); vm_map_reference(map); vm_map_deallocate(map); vm_map_insert(map, object, offset, start, end, prot, max, cow); vm_map_findspace(map, start, length, addr); vm_map_lookup(map, address, entry); vm_map_inherit(map, start, end, new_inheritance); vm_map_clean(map, start, end, syncio, invalidate); -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-platforms Sat Nov 30 08:17:58 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24118 for platforms-outgoing; Sat, 30 Nov 1996 08:17:58 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24108; Sat, 30 Nov 1996 08:17:53 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id LAA10829; Sat, 30 Nov 1996 11:17:30 -0500 (EST) From: "John S. Dyson" Message-Id: <199611301617.LAA10829@dyson.iquest.net> Subject: Re: FreeBSD/MIPS anybody To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Sat, 30 Nov 1996 11:17:30 -0500 (EST) Cc: toor@dyson.iquest.net, msmith@atrad.adelaide.edu.au, imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org In-Reply-To: <5734.849370433@critter.tfs.com> from "Poul-Henning Kamp" at Nov 30, 96 05:13:53 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > >I started a VM doc, but lost it in a disk crash. I might be able > >to start one again, but it would be a week or so at least to > >write (to complete.) Can't promise anything in the next week > >or so though, as bugs like the MSDOS problem appear regularly. > > Would this by any chance be a help ? > Yep, that will save a big part of a day!!! Thanks. At least I have some basic info again. It doesn't look like much, but referring back and forth to the source code is quite time consuming. Thanks again!!! John From owner-freebsd-platforms Sat Nov 30 09:41:25 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA27409 for platforms-outgoing; Sat, 30 Nov 1996 09:41:25 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA27403; Sat, 30 Nov 1996 09:41:22 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id JAA19857; Sat, 30 Nov 1996 09:40:47 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611301740.JAA19857@GndRsh.aac.dev.com> Subject: Re: FreeBSD/MIPS anybody In-Reply-To: <199611301539.KAA10646@dyson.iquest.net> from "John S. Dyson" at "Nov 30, 96 10:39:45 am" To: toor@dyson.iquest.net (John S. Dyson) Date: Sat, 30 Nov 1996 09:40:47 -0800 (PST) Cc: msmith@atrad.adelaide.edu.au, toor@dyson.iquest.net, imp@village.org, platforms@FreeBSD.org, dyson@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > Of course, if I'm wrong and it's actually totally trivial, then I'll > > just go sit in the corner and cry 8) Any chance of a pmap(9) manpage > > detailing its features and requirements? 8) > > > PS, I FULLY intend to document the VM system. The more noise that > is made about it, the higher priority it becomes. I am sure that > if everyone said: I don't care about LFS for now, etc -- then I would be > very willing to do the docs... Frankly, I am not in a programming > mood right now, so it might not be a bad thing. > > Perhaps if DG and I produced more docs, then we could get more > parallel efforts going. Actually, there are other kernel hackers > that appear to be coming up to speed quite nicely (which is really > a wonderful thing.) Maybe we can get the ball rolling!!! Have you ever tried to go buy a good book on VM system design? I seem to remeber a day when David and myself where down at Powell technical book store and he purchased one of the OSF manuals just because it had a whole chapter on the VM system. IMHO, a ``book'' written by one of the technical staff of O'Reiley with John Dyson and David Greenman as the technical contributors would fill a VERY LARGE void on many a persons technical library shelf/book case/ library! I book sounds like a daunting task, but books often get created from smaller documentation processes, and if we can get you two to write us 10 pages on the pmap code, perhaps a technical writter can be recruited someplace to grow this start into something larger. Even a 10 page paper would be well recieved at many of the technical conferences, though I am not sure how you feel about doing paper presentations :-). Just my $0.05 worth... you can hit delete now :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD