From owner-freebsd-hackers Fri Jul 16 3:55:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nitek.ru (nitek.east.ru [195.170.63.240]) by hub.freebsd.org (Postfix) with ESMTP id 2E22E14C3C for ; Fri, 16 Jul 1999 03:55:10 -0700 (PDT) (envelope-from maillist@nitek.ru) Received: from nitek.ru (localhost [127.0.0.1]) by gate.nitek.ru (8.9.1/8.9.1) with SMTP id OAA15630 for hackers@FreeBSD.org; Fri, 16 Jul 1999 14:54:51 +0400 (MSD) Date: 16 Jul 1999 14:54:51 +0400 From: "Daniel C. Sobral" To: hackers@FreeBSD.org Message-ID: <378F0E28.BE5CE95E@newsguy.com> Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Something is weird here. If the solaris people are using a > SWAPSIZE + REALMEM VM model, they have to allow the > allocated + reserved space go +REALMEM bytes over available swap > space. If not they are using only a SWAPSIZE VM model. I did not check if the model was a SWAPSIZE+REALMEM or a SWAPSIZE model. Anyway, I think you are assuming that the "swap -s" command shows as total memory just the swap space... Maybe, maybe not. I don't know. But the space against which I reached the ceiling *was* the one reported in the "swap -s" command. > Wait - does Solaris normally use swap files or swap partitions? > Or is it that weird /tmp filesystem stuff? If it normally uses swap > files and allows holes then that explains everything. I'd say partitions. While perusing man pages, I caught briefly the comment that a swap partition could overwrite a normal partition, in a man page about a special command to create swap partitions. Anything you'd like me to check in particular? If you have any source code you'd like me to run, just send it to capo@comp.cs.gunma-u.ac.jp, though I can only run them at the earliest on monday. Well, at least my monday is your sunday night... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message