From owner-freebsd-hackers Sun Dec 20 15:48:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07495 for freebsd-hackers-outgoing; Sun, 20 Dec 1998 15:48:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07487 for ; Sun, 20 Dec 1998 15:48:19 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA07216; Sun, 20 Dec 1998 15:42:05 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdgC7201; Sun Dec 20 23:42:03 1998 Date: Sun, 20 Dec 1998 15:41:59 -0800 (PST) From: Julian Elischer To: zhihuizhang cc: hackers Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you commenting the source as you go? Are yu writing a document on these things? you seem to be going through the entire kernel :-) If so. can we get a copy :-) julian On Sat, 19 Dec 1998, zhihuizhang wrote: > > Hi, > > I have some questions about the routine vm_fault() in the file vm_fault.c: > > (1) The condition (!change_wiring || wired) is always TRUE! Three possible > values of change_wiring are FALSE (0), VM_FAULT_CHANGE_WIRING (1), and > VM_FAULT_USER_WIRE (2). When its value is VM_FAULT_CHANGE_WIRING or > VM_FAULT_USER_WIRE, the wired count of the map entry has already been > incremented (see vm_map_user_pageable() and vm_map_pageable()), so > vm_map_lookup() will set wired as non-zero. If the argment's value is > FALSE, the condition is trivially true. > > (2) Following the label readrest: in the source code, there are some codes > trying to handle read ahead for sequential objects. However, the following > statement is wrong: > > for (tmppindex = first_index - 1; tmppindex >=first_pindex; -- tmppindex) > > We should probably use firstpindex instead of first_pindex in the comparison > (pay attention to the underscore here). However, the for loop will not loop > forever, because vm_page_lookup() called within the loop will return NULL > anyway. > > (3) If the pager fails to bring in a page for the very first object in the > shadow chain, the page will contain invalid content. If the pager fails to > bring in a page for other objects in the shadow chain, the page is freed > and invalid. Yet, we still reference to that page (m) later. This means > that after the page fault, we could get a page with invalid contents. > There is a XXX near the related comment in the source code. > > (4) The comment in the source code says that the pager can move a page, so > we must relookup the page by calling vm_page_lookup(). How could this be > the case? Why move the page? > > (5) The comment in the source code says that we do not COW read-only region > on a user wire. "If we do not make this restriction, the bookkeeping would > be nearly impossible." Can anyone explain this for me? > > (6) The comment in the source code says map entries may be pageable. I really > doubt this because vm_map_entry_create() always allocates wired down memory > for new map entries and enter them into pmap immediately. > > (7) The comment in the source code says pmap_enter() may cause other faults. > I can not see any reason for this to happen. > > I am just wondering how this important routine in VM system can have these > imperfect things (except (4) through (7)). I hope I am wrong. Please help > me out with understanding of these points. > > Any help is appreciated. > > -------------------------------------------------- > | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | > | Dept. of Computer Science, SUNY at Binghamton | > -------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message