From owner-freebsd-hackers Thu Dec 24 00:13:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA00821 for freebsd-hackers-outgoing; Thu, 24 Dec 1998 00:13:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA00815 for ; Thu, 24 Dec 1998 00:13:29 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 14517 invoked from network); 24 Dec 1998 08:13:14 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 24 Dec 1998 08:13:14 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id DAA46747; Thu, 24 Dec 1998 03:13:11 -0500 (EST) Message-Id: <199812240813.DAA46747@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: from Julian Elischer at "Dec 20, 98 03:41:59 pm" To: julian@whistle.com (Julian Elischer) Date: Thu, 24 Dec 1998 03:13:11 -0500 (EST) Cc: bf20761@binghamton.edu, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] 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 Julian Elischer said: > 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 :-) > I would also be willing to review it (to help.) > > > > (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? > > Device pager allocates it's own page as needed. Specifically, hardware VM pseudo devices have more freedom with this (questionable) ability. > > > (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? > > As I remember, it is quite complex to handle it correctly for debuggers and other such situations. > > > (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. > That is quite an anachronism, and that comment should be totally ignored. > > > > (7) The comment in the source code says pmap_enter() may cause other faults. > > I can not see any reason for this to happen. > > It doesn't on the X86, but *might* elsewhere. At one time I thought about doing that, but found it to be evil (due to possible deadlocks and lock handling.) On the X86, I handled the issue(s) differently. > > > 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. > > The code isn't perfect, but there are lots of subtile reasons things being the way that they are, and also sometimes bugs that just don't get exercised. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message