From owner-freebsd-hackers Mon Jun 12 11:59:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA11470 for hackers-outgoing; Mon, 12 Jun 1995 11:59:47 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA11464 for ; Mon, 12 Jun 1995 11:59:43 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19130; Mon, 12 Jun 95 12:51:35 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506121851.AA19130@cs.weber.edu> Subject: Re: performance... To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 12 Jun 95 12:51:34 MDT Cc: gibbs@freefall.cdrom.com, nate@trout.sri.mt.net, hackers@freebsd.org In-Reply-To: <199506112208.PAA02703@rah.star-gate.com> from "Amancio Hasty" at Jun 11, 95 03:08:29 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > Perhaps better page trimming algorithm for processes? > > VMS had a nice process memory page controlling algorithm, > number of pages to add or delete based on the rate of > paging, etc.. and tunable... VMS called theirs a "Working Set Quota" (WSQUOTA). I believe that FreeBSD has a similar quota systems to avoid a simgle process trashing the cache (like what happens when you run the linker in UnixWare). Actually, I'd like to see a paper on the new VM system; I've been considering Dynix-like per processer page caches and other issues of concurrency. It'd be nice to know the intended overall design (plus such a paper would probably have historical significance 8-)). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.