From owner-freebsd-hackers Sun Sep 30 1: 2:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from milliways.chance.ru (milliways.chance.ru [195.190.107.35]) by hub.freebsd.org (Postfix) with ESMTP id 816E537B40F for ; Sun, 30 Sep 2001 01:02:08 -0700 (PDT) Received: from do-labs.spb.ru (ppp-6.chance.ru [195.190.107.9]) by milliways.chance.ru (8.9.0/8.9.0) with SMTP id MAA02230 for ; Sun, 30 Sep 2001 12:01:56 +0400 (MSD) Received: (qmail 735 invoked by uid 1000); 30 Sep 2001 12:03:28 -0000 Date: Sun, 30 Sep 2001 12:03:28 +0000 From: Vladimir Dozen To: Alfred Perlstein Cc: Vladimir Dozen , Matt Dillon , Wilko Bulte , hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) Message-ID: <20010930120328.A534@eix.do-labs.spb.ru> References: <20010929155941.A291@eix.do-labs.spb.ru> <20010929071024.Q59854@elvis.mu.org> <20010929141349.A80876@freebie.xs4all.nl> <200109291653.f8TGrRR37689@earth.backplane.com> <20010929232953.B341@eix.do-labs.spb.ru> <20010929175653.Z59854@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010929175653.Z59854@elvis.mu.org>; from bright@mu.org on Sat, Sep 29, 2001 at 05:56:53PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ehlo. > My suggestion, (but not my final say, i'm still open to ideas): > > Implement a memory status signal to notify processes of changes > in the relative amount of system memory. > > When memory reaches a low or high watermark, the signal is > broadcast to all running processes. > > The default disposition will be to ignore the signal. > > The signal will be named SIGMEMINFO. (SIGXfoo means > 'process has exceeded resource foo') Agreed. As for SIG_IGN, can anyone tell me -- can I force existing application to use my signal handler? For example, by preallocating some shared library? If so, there are no contras for ignoring signal by default. > The signal will pass via the siginfo struct information > such that the process can determine if the system has > just exceeded the low watermark (danger) or has reclaimed > down to the high watermark (enough free memory). Passing more info is always better. Agreed. > a) over allocate swap a bit and set the low watermark carefully. > b) do the following enhancement: > > Provide a system whereby you can swap to the filesystem without > additional upcalls/syscalls from userspace, basically, provide > some means of paging to the filesystem automatically. > > then, set your lowwater mark to the size of your swap partition, > now your system will alert your processes and automatically swap > _anyone_ to the filesystem. > > I really think that this would be more flexible and still allow > you to achieve what you want... What do you think? I can't say anything until I'll got detail. Sorry, English is neither my native nor used often, so I may easely miss important details, but here is my random comments: Initally, I was trying the same (I think) approach, but there was some problems. Some kernel function refused to work with VM objects of processes differing from curproc. I.e., it could be hard to work with bigproc inside swap daemon; and swap daemon is the only place where we can detect OOM condition; that's why I used signal to transfer control to user space, and then back into kernel -- already in another process. Another reason to do it -- to make all limits and quota work automatically. Also, I did not wanted to make swap daemon busy too long. Also, what means "over allocate swap a bit"? How to compute the value of that bit? At what moment should we preallocate? Should we repeat preallocation after getting SIGMEMINFO (himark)? Also, you cannot set low mark to size of swap partition. To create file-based swap you need some memory (file operations requires it). So, low mark should be a bit lower (that's why I raised value of nswap_lowat). Finally, if you want to over allocate swap for every process in system, the whole swap can wind up consisting of only preallocations. Resource management is the role of kernel. Any hard reservation interfere with that. -- dozen @ home To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message