From owner-freebsd-current Mon May 7 12:11:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0F7B837B422 for ; Mon, 7 May 2001 12:11:28 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f47JBCD64553; Mon, 7 May 2001 12:11:12 -0700 (PDT) (envelope-from dillon) Date: Mon, 7 May 2001 12:11:12 -0700 (PDT) From: Matt Dillon Message-Id: <200105071911.f47JBCD64553@earth.backplane.com> To: Rik van Riel Cc: Alfred Perlstein , Sheldon Hearn , Kris Kennaway , Dennis Glatting , , Subject: Re: pgm to kill 4.3 via vm References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> For some reason banning you from the irc channel hasn't convinced :> you that complaining without providing patches isn't the way we do :> things around here. : :How about first analysing the problem in detail and :trying to fix it after we understand the problem ? : :The current stage is that I've pretty much figured out :the problem and know why the code in FreeBSD and NetBSD :doesn't currently work (while it would have worked in :the original Mach VM). : :A next stage is getting some smart people together :and coming up with a thorough solution. : :"Patch first, think later" is definately not the :attitude I'm used to seeing in the FreeBSD world, :no matter how often you and phk have shouted this at :me yesterday ;) Well, we'll see what you have to say in your paper. VM/Swap is a tough nut to crack... remember when I thought I had optimized the pageout daemon to not launder dirty pages unnecessarily? And then it turned out that, in fact, the pageouts were necessary to maintain stability in certain environments (like USENET news servers). That was somewhat embarassing because I waxed poetic to you and Linus and then had to correct myself and revert part of the optimization after real-life problems started cropping up. About 8 months ago I introduce code that would prevent sequential reads of large files from blowing away the rest of the system's VM page cache, to reduce the impact sequential reads would have in a heavily loaded system. It's a wonderful idea and I had thought up a great algorithm... too bad it didn't work in real life. It took a month to find all the edge cases and change the algorithm to be more of a heuristic to handle them all. I'm still not completely happy with it so at the moment it's only used by madvise(). At some point soon I am going to make the buffer cache use it, though. In anycase... insofar as VM goes, A theory doesn't usually last beyond the first implementation. So "we'll see". -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message