From owner-freebsd-hackers Mon Oct 1 1:37: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from moon.quantum.ru (Moon.quantum.ru [213.170.64.43]) by hub.freebsd.org (Postfix) with ESMTP id 950B637B410 for ; Mon, 1 Oct 2001 01:37:02 -0700 (PDT) Received: from osw.com.ru (miha.quantum.ru [213.170.81.110]) by moon.quantum.ru (8.9.3/8.9.3) with SMTP id MAA05282 for ; Mon, 1 Oct 2001 12:37:00 +0400 (MSD) Received: (qmail 11550 invoked from network); 1 Oct 2001 08:36:26 -0000 Received: from ws4.osw.intranet (HELO osw.com.ru) (192.168.0.4) by gw.osw.intranet with SMTP; 1 Oct 2001 08:36:26 -0000 Message-ID: <3BB82BAD.6090301@osw.com.ru> Date: Mon, 01 Oct 2001 12:39:09 +0400 From: Vladimir Dozen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: ru, en-us MIME-Version: 1.0 To: Alfred Perlstein Cc: Greg Lehey , Jos Backus , hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) References: <20010929232953.B341@eix.do-labs.spb.ru> <20010929175653.Z59854@elvis.mu.org> <20010930120328.A534@eix.do-labs.spb.ru> <20010930035529.G59854@elvis.mu.org> <20010930134437.B284@eix.do-labs.spb.ru> <20010930105509.B2220@lizzy.bugworks.com> <20010930142326.L59854@elvis.mu.org> <20010930123359.A7241@lizzy.bugworks.com> <20010930145558.M59854@elvis.mu.org> <20011001131951.M31215@wantadilla.lemis.com> <20010930234114.P59854@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. > Well Joe seems to have provided a pretty interesting document on > how it works in AIX, but I was wondering if they do anything wrt > low/high watermarks like my idea. > > Basically you'd like to inform processes that the danger has been > alliviated so that they can cautiously start accepting more work > rather than freaking out and shutting out clients forever... Actually, most of applications believe that everything OK except something tells them it's not. Regular OOM protection may be build as: int on_sigdanger(int) { throw std::runtime_error("out of memory"); } ... while( there_are_more_requests ) { try { do_some_work_eating_lot_of_memory(); } catch(const std::exception& ex) { cerr << ex.what() << endl; } } I.e, we will attempt to execute user requests while we have them in our queue, but we will get exceptions and stop processing if system is out of memory. As soon as system will get enough free space we will continue normal processing without any special handling from our side. It means that signal that opposite SIGDANGER is rarely required, if required at all. You should be glad, it reduces work to do. ;) P.S. I know that throwing inside signal handler is bad techique, but it works (and works better than setting flag and testing it everywhere). dozen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message