Date: Sun, 17 May 1998 00:30:24 +0200 From: Eivind Eklund <eivind@yes.no> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf param.c src/sys/kern uipc_domain.c uipc_proto.c uipc_socket.c uipc_socket2.c uipc_usrreq.c src/sys/ Message-ID: <19980517003024.49844@follo.net> In-Reply-To: <199805162159.OAA13568@usr02.primenet.com>; from Terry Lambert on Sat, May 16, 1998 at 09:59:49PM %2B0000 References: <19980516200156.30364@follo.net> <199805162159.OAA13568@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 16, 1998 at 09:59:49PM +0000, Terry Lambert wrote:
> > To get around that problem, I'd expand the VM space in the top half of
> > the kernel ("somewhere suitable") when it looked like we were "close
> > to" running out of space (ie, close to the maxsockets case), and
> > probably start out with maxsockets somewhat smaller. (There are, of
> > course, a lot of opportunities for high-water/low-water mark magic
> > around this).
> >
> > Does it sound doable?
>
> The protection you would gain is statistical; there would still be
> failure races if you did it (consider a low memory condition; just
> because you can expand the page mappings doesn't mean that you will
> have pages available for them to point to).
Sure, it is a race condition for failure - just as the present one is
(unless those maxsockets _really_ are the maximum limit for the number that
can be needed). However, it would make it much less likely to fail, and if
we _can't_ make it impossible to fail it is worthwhile to just better the
odds :-)
> This is why type stable memory is so annoying. 8-).
Can't see that that makes things much different. I'd say this is why having
to allocate things in the bottom half of the kernel is annoying. "Got to
roll with the punch" etc.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980517003024.49844>