Date: 22 Jan 1999 14:23:39 +0200 From: Ville-Pertti Keinonen <will@iki.fi> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@FreeBSD.ORG Subject: Re: Review and report of linux kernel VM Message-ID: <8690evpkc4.fsf@not.oeno.com> In-Reply-To: dillon@apollo.backplane.com's message of "14 Jan 1999 09:21:08 %2B0200" References: <199901140720.XAA22609@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
dillon@apollo.backplane.com (Matthew Dillon) writes: > In general terms, linux's VM system is much cleaner then FreeBSD's... and > I mean a *whole lot* cleaner, but at the cost of eating some extra memory. Whaat? You appear to be confusing cleanliness (as I understand it, and I'm afraid that many other readers of your review might understand it) with simplicity. I would claim the exact opposite. The Linux VM system is simpler, but far *less* clean because of the very inflexible (almost non-existent) "layers". Not to mention the code, which shares the (IMHO) poor source organization and apparently arbitrary dependencies of Linux as a whole. The Linux VM system looks like it hasn't been designed at all, just implemented. The basic organization (although not that much of the code) is still based on versions of Linux that only had one page table for all tasks, was fully i386-specific (complete with hard-coded constants all over the place), implemented shared libraries by having a per-task array of shared library addresses, sharing pages by scanning through all tasks to find one with the same library etc. Subsystems in Linux don't seem to get re-written, they only evolve. Perhaps my critique addresses the Linux code more than the functionality...but they are related. What's my definition of clean then? For example, common operations shouldn't need to resort to brute-forceish approaches (not in many cases, anyhow). Which reminds me, your swp_pager_meta_free_all looks a bit frightening...do you intend to keep it like it is? > Problems ... In addition to the problems you stated, as far as I can tell, swap backing is not shared for copy-on-write associations (copy-on-write pages get swapped out multiple times, all but the last don't free any memory) unless the page was swapped out when the maps were copied, in which case it ends up copy-on-access...maybe, I'm not sure whether the swap cache eliminates this. This (and many of the things you pointed out) is due to the simplistic approach where pages don't really have an identity (only mappings) unless they are backed by an inode. Which is perhaps at the core of most of the algorithmic differences between Mach/4.4BSD and Linux VM systems. IMHO pages need to have an identity even when they are not associated with files (based on a quick glance, NetBSD's UVM seems to retain this property while optimizing the management of anonymous pages. I'm not convinced in terms of the choice of data structures for the anon maps in UVM, though). > reference information. Instead, it uses the vm_object and pmap modules. > I actually like this feature of FreeBSD. A lot. Additionally, the way FreeBSD does things has better potential for concurrency (even though the locks have been ripped out) compared to Linux. > 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. 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?8690evpkc4.fsf>