Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Sep 2001 04:22:36 -0500
From:      Alfred Perlstein <bright@mu.org>
To:        Rik van Riel <riel@conectiva.com.br>
Cc:        Vladimir Dozen <vladimir-dozen@mail.ru>, Matt Dillon <dillon@earth.backplane.com>, Wilko Bulte <wkb@freebie.xs4all.nl>, hackers@FreeBSD.ORG
Subject:   Re: VM: dynamic swap remapping (patch)
Message-ID:  <20010930042236.H59854@elvis.mu.org>
In-Reply-To: <Pine.LNX.4.33L.0109300514360.19147-100000@imladris.rielhome.conectiva>; from riel@conectiva.com.br on Sun, Sep 30, 2001 at 06:11:49AM -0300
References:  <20010929175653.Z59854@elvis.mu.org> <Pine.LNX.4.33L.0109300514360.19147-100000@imladris.rielhome.conectiva>

next in thread | previous in thread | raw e-mail | index | archive | help
* Rik van Riel <riel@conectiva.com.br> [010930 04:12] wrote:
> On Sat, 29 Sep 2001, Alfred Perlstein wrote:
> > * Vladimir Dozen <vladimir-dozen@mail.ru> [010929 14:38] wrote:
> >
> > > P.S. Anyway, I do NOT insist my solution is better, and even that it
> > >      is good for anything at all. It was fun for me to hack in BSD kernel,
> > >      and it was interesting challenge, and I feel need to share results
> > >      with others. At worst, I will recommend our customer to setup
> > >      processing farm under FreeBSD with applied patch.
> >
> > I'm really impressed with the work you put into this, but it seems
> > that you've tried to tackle two problems at the same time,
> 
> Indeed, the whole idea of swapping tasks to the filesystem
> in nice, but having the task do this all by itself isn't a
> good option for many people...
> 
> > 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')
> 
> That'd be SIGDANGER, right ?

Sort of.

> 
> > 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.
> 
> Sounds like a winner, when swap runs out a process gets
> suspended onto the filesystem automatically and SIGDANGER
> is sent out to give others a chance to clean themselves
> up.

Well, no, the idea is to have a low and high watermark so that
flip-flopping on the boundry doesn't generate a lot of signals.

SIGDANGER is ok for a name, but slightly misleading because
I wanted to piggyback some info in the siginfo to tell processes
when the danger has passed.  Well ok, the name is ok, but
I do want an upcall when the situation is alleviated.

Let me also state that it may be wise to add huristics to the
system to not SIGDANGER anything that is completely swapped
out or hasn't run in a long time, this would avoid a spike
in thrashing at the time of the broadcast.

> If enough space is freed, the suspended process can get
> back into the system.
> 
> This should also preserve leaky applications while at the
> same time leaving the system intact...

Hopefully, also having a SIGDANGER handler may be an indication
to the kernel to give you a second chance before shooting at
you, I know it could be used to subvert behavior to have another
niave program killed, however that could be a tunable to give
those trying to do the right thing a second chance.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'

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?20010930042236.H59854>