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>