Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Dec 1998 03:13:11 -0500 (EST)
From:      "John S. Dyson" <dyson@iquest.net>
To:        julian@whistle.com (Julian Elischer)
Cc:        bf20761@binghamton.edu, freebsd-hackers@FreeBSD.ORG
Subject:   Re: questions/problems with vm_fault() in Stable
Message-ID:  <199812240813.DAA46747@y.dyson.net>
In-Reply-To: <Pine.BSF.3.95.981220154047.8357P-100000@current1.whistle.com> from Julian Elischer at "Dec 20, 98 03:41:59 pm"

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



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