Date: Mon, 01 Oct 2001 12:39:09 +0400 From: Vladimir Dozen <dozen@osw.com.ru> To: Alfred Perlstein <bright@mu.org> Cc: Greg Lehey <grog@FreeBSD.ORG>, Jos Backus <josb@cncdsl.com>, hackers@FreeBSD.ORG Subject: Re: VM: dynamic swap remapping (patch) Message-ID: <3BB82BAD.6090301@osw.com.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BB82BAD.6090301>