Date: Mon, 25 Jan 1999 03:43:12 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: will@iki.fi (Ville-Pertti Keinonen) Cc: dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: Review and report of linux kernel VM Message-ID: <199901250843.DAA00649@y.dyson.net> In-Reply-To: <8690evpkc4.fsf@not.oeno.com> from Ville-Pertti Keinonen at "Jan 22, 99 02:23:39 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Ville-Pertti Keinonen said: > > > Linux demarks interrupts from supervisor code much better then we do. > > You seem to consider simpler to mean cleaner/better. Although in this > case, I'd agree that much of the complexity of FreeBSD is unnecessary. > I agree with you. Additionally, my observation (after >20yrs of experience) is that a lack of understanding sometimes prejudices an individual about a given codebase. With alot of experience with a given code technology, one can also pick out the various algorithms and schemes used in a (for example VM system), and understand it rapidly also. So, it would likely take someone who has not only supported and minimally modified a VM system, but actually created an advanced one to come up to speed quickly on FreeBSD. The good thing about such an individual is that the code would really improve, but the bad thing is that it would change significantly, and might destabilize a little bit, like it used to :-). Often, I would "see a picture" as to how the code should work, and engineer fairly good solutions to various VM issues, but my coding and programming skills werent' always perfect. I am trying to support the new VM maintainers as much as reasonable (trying to help, for both altruistic and selfish reasons), but eventually, they will be able to comfortably fly on their own. From my observation, it still seems that there is a learning curve involved, but the new people seem to be very aggressively traversing that curve. The method of working from the outside- in is good, because it allows the proper testing of components (like the swap pager), and slowly develop and understanding of the design ramifications. For example, there is a design choice in the new swap pager that I am not sure about, and have reminded the new developer that maybe the code needs to be evaluated because of the change. That doesn't necessarily mean that the change is BAD, but does mean that since the code previously worked pretty well, and there are improvements in the new code, but there might also be some regressions. It is important to make sure that the regressions don't add up along with the improvements :-). The FreeBSD VM is generally layered fairly well, except for the shortcuts in management of collapsing objects. There are also some problems with the VFS interface to the VM code (and where the most advantage could be gained by improving that interface.) I originally bypassed the layering for files/raw devices, and found that to be very (extremely) evil -- so the vnode pager now has both default capabilites, and a layered capability. There are some complexities associated with freeing pages at interrupt time (generally tricky in FreeBSD), and creating map entries at interrupt time (you have to use kmem_map for that, because it is protected from interrupts.) The complications with freeing pages at interrupt time are one set of reasons for still needing a free queue -- the cache queue consists of pages that are not free, and in order to allocation pages anew from the cache queue, pages have to be logically freed. A recent discussion between a new VM maintainer and myself ensued regarding the complexities of the cache queue... Most of those complexities are associated with the cache queue having attributes of both the free queue AND the queues with pages still valid. However, without the cache queue, suboptimal page management algorithms would become much more apparent (maybe the cache queue should be disabled for testing purposes? :-)). The worst evil in all of this is that it is impossible to maintain coherency in the VFS layering scheme (as it is today), without lots of calls between layers, and great inefficiency (imagine handling mapped pages at each layer in the VFS hierarchy, and maintain mutual coherency and coherency with normal file I/O!!! :-(). The only scheme that I know of that would be sane would be a DSM style abstraction, with an implementation that shortcircuts the abstraction when it doesn't break things (and gains the most efficiency.) -- 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?199901250843.DAA00649>