Hi everyone,
I've been following this discussion almost from the beginning, and I
have the feeling that we're not _really_ getting very far. There's good
arguments for and against overcommit, depending on your point of view
and your requirements.
What I do see is a not-so-openly voiced consent t
Mike Smith wrote:
>
> > On Tue, 13 Jul 1999, Mike Smith wrote:
> >
> > > 'siobi' is someone trying to open the serial console, for whatever
> > > reason. Without knowing who it was that was stuck there, it's hard to
> > > guess what is going on.
> >
> > D'uh, sorry. Long day. It was amd tha
Daniel Eischen writes:
> There are some bugs in libc_r in stable that have been fixed in
> -current. I think the one that you've hit is an uninitialized
> TAILQ_HEAD in a statically declared mutex (in localtime). It's
> probably about time for a MFC. If someone wants to give me the
> go-ahead,
> On Tue, 13 Jul 1999, Mike Smith wrote:
>
> > 'siobi' is someone trying to open the serial console, for whatever
> > reason. Without knowing who it was that was stuck there, it's hard to
> > guess what is going on.
>
> D'uh, sorry. Long day. It was amd that was hung in the siobi
> state.
On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote:
> >
> > If you have a lot of users, all of which have buggy programs which eat
> > a lot of memory, per-user swap quotas don't necessarily save your butt.
>
> The chance of these buggy programs running at the same time is not
> exa
> Is the reason why adb hasn't been ported to freebsd because the source is
> proprietary?
You make no sense.
> If gdb should suffice for my debugging needs, how can a breakpoint be set
> at a particular interrupt, or even at any interrupt? The break command
> only seems to accept functions, offs
>
> And what do you do, then, with the processes that happen to have
> legitimate use for more stack?
>
> Or maybe you just find out how much stack each process uses, and
> then set limits appropriate for each one? Which is the equivalent of
> setting limits to each user, of course...
You get a
Daniel Eischen <[EMAIL PROTECTED]> writes:
> There are some bugs in libc_r in stable that have been fixed in
> -current. I think the one that you've hit is an uninitialized
> TAILQ_HEAD in a statically declared mutex (in localtime). It's
> probably about time for a MFC. If someone wants to giv
> On Tue, 13 Jul 1999, Mike Smith wrote:
>
> > 'siobi' is someone trying to open the serial console, for whatever
> > reason. Without knowing who it was that was stuck there, it's hard to
> > guess what is going on.
>
> D'uh, sorry. Long day. It was amd that was hung in the siobi
> state.
On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote:
> >
> > If you have a lot of users, all of which have buggy programs which eat
> > a lot of memory, per-user swap quotas don't necessarily save your butt.
>
> The chance of these buggy programs running at the same time is not
> ex
> Is the reason why adb hasn't been ported to freebsd because the source is
> proprietary?
You make no sense.
> If gdb should suffice for my debugging needs, how can a breakpoint be set
> at a particular interrupt, or even at any interrupt? The break command
> only seems to accept functions, off
lyn...@orthanc.ab.ca wrote:
>
> What it so evil about having a reasonably intelligent malloc() that
> tells the truth, and returns unused memory to the system? Overcommit
> is for lazy programmers, plain and simple. At least the SGI documentation
> about overcommit admits that (or at least, did at
Jason Thorpe wrote:
>
> If you have a lot of users, all of which have buggy programs which eat
> a lot of memory, per-user swap quotas don't necessarily save your butt.
The chance of these buggy programs running at the same time is not
exactly high...
> And maybe the individual programs didn't e
John Nemeth wrote:
>
> The machine in question has run out of swap, due to unforseeable
> excessive memory demands. This was accompanied by processes
> complaining about not being able to allocate memory and then cleaning
> up after themselves. I did not see random processes being killed
>
Michael Richardson wrote:
>
> Ben> Tell me, Mr. Nemeth, has this ever happened to you? Have you ever
> Ben> come *close*?
>
> Uh, since we don't run overcommit, the answer is specifically *NO*.
And what system do you run?
> I have had it happen on other systems. (Solaris, AIX) It w
Michael Richardson wrote:
>
> No, I don't agree.
>
> This is a biggest argument against solving the overcommit situation with
> SIGKILL. I have no problem with overcommit as a concept, I have a problem
> with being unable to keep my possibly big processes (X, rpc.nisd,
> etc. depending on cic
John Nemeth wrote:
>
> On one system I administrate, the largest process is typically
> rpc.nisd (the NIS+ server daemon). Killing that process would be a
> bad thing (TM). You're talking about killing random processes. This
> is no way to run a system. It is not possible for any arbitrar
>
> And what do you do, then, with the processes that happen to have
> legitimate use for more stack?
>
> Or maybe you just find out how much stack each process uses, and
> then set limits appropriate for each one? Which is the equivalent of
> setting limits to each user, of course...
You get a
:
:On Jul 15, 12:20am, "Daniel C. Sobral" wrote:
:} "Charles M. Hannum" wrote:
:} >
:} > That's also objectively false. Most such environments I've had
:} > experience with are, in fact, multi-user systems. As you've pointed
:} > out yourself, there is no combination of resource limits and what
:> I mean, jeeze, the reservation for the program stack alone would eat
:> up all your available swap space! What is a reasonable stack size? The
:> system defaults to 8MB. Do we rewrite every program to specify its own
:> stack size? How do we account for architectural differen
:Ted Faber
:>For every strategy there's a counterstrategy.
:exactly: the disappointing thing about this whole thread is there's been
:little discussion of implementing a (tunable) policy how to handle the
:situation when resource shortage materialises.
:
:Overcommitment can be useful, maybe even f
:Our IMAP server routinely show a footprint of about 1MB private storage.
:This is constant for most operations. However, when you get into doing
:SEARCH and SORT, there are certain cases where we need memory, sometimes
:a *lot* of memory.
:
:Your proposal is that my *well behaved* application shou
Sergey Babkin wrote:
>
> > It would be nice to have a way to indicate that, a la SIGDANGER.
>
> Another option may be to add something like "importance classes".
> Suppose we assign an one-byte "importance level" to each process.
> When we get out of swap we start killing processes with the lowes
Jason Thorpe wrote:
>
> If you have a lot of users, all of which have buggy programs which eat
> a lot of memory, per-user swap quotas don't necessarily save your butt.
The chance of these buggy programs running at the same time is not
exactly high...
> And maybe the individual programs didn't
[EMAIL PROTECTED] wrote:
>
> What it so evil about having a reasonably intelligent malloc() that
> tells the truth, and returns unused memory to the system? Overcommit
> is for lazy programmers, plain and simple. At least the SGI documentation
> about overcommit admits that (or at least, did at o
Jason Thorpe wrote:
>
> > > ...um, so, make the code that deals with faulting in the stack a bit
> smarter.
> >
> > Uh? Like what? Like overcommitting, for instance? The beauty of
> > overcommitting is that either you do it or you don't. :-)
>
> One option is to special-case overcommit the s
Robert Elz wrote:
>
> Note that all this (large) VM I have described was filled with real data
> (except for the odd times hen innd or named had just forked), none of it
> could be overcommitted and just ignored. Whatever policy was in place,
> the physical VM resources would have run out.
In a
John Nemeth wrote:
>
> } > But that isn't always the best process to have killed off...
> }
> } Sure it is. :-) Let's see...
>
> This statement is absurd. Only a comptetant admin can decide
> which process can be killed. No arbitrary decision is going to be
> correct.
We are talking about
John Nemeth wrote:
>
> The machine in question has run out of swap, due to unforseeable
> excessive memory demands. This was accompanied by processes
> complaining about not being able to allocate memory and then cleaning
> up after themselves. I did not see random processes being killed
>
John Nemeth wrote:
>
> } > This is based upon your somewhat strange definition of "work". I assure
> } > you that I have run many systems which don't use overcommit, and which I
> } > quite frequently run into "out of VM" conditions, and which I can assure
> } > you, work just fine. When they'
Michael Richardson wrote:
>
> Ben> Tell me, Mr. Nemeth, has this ever happened to you? Have you ever
> Ben> come *close*?
>
> Uh, since we don't run overcommit, the answer is specifically *NO*.
And what system do you run?
> I have had it happen on other systems. (Solaris, AIX) It
Michael Richardson wrote:
>
> No, I don't agree.
>
> This is a biggest argument against solving the overcommit situation with
> SIGKILL. I have no problem with overcommit as a concept, I have a problem
> with being unable to keep my possibly big processes (X, rpc.nisd,
> etc. depending on ci
John Nemeth wrote:
>
> On one system I administrate, the largest process is typically
> rpc.nisd (the NIS+ server daemon). Killing that process would be a
> bad thing (TM). You're talking about killing random processes. This
> is no way to run a system. It is not possible for any arbitra
:
:On Jul 15, 12:20am, "Daniel C. Sobral" wrote:
:} "Charles M. Hannum" wrote:
:} >
:} > That's also objectively false. Most such environments I've had
:} > experience with are, in fact, multi-user systems. As you've pointed
:} > out yourself, there is no combination of resource limits and wha
:> I mean, jeeze, the reservation for the program stack alone would eat
:> up all your available swap space! What is a reasonable stack size? The
:> system defaults to 8MB. Do we rewrite every program to specify its own
:> stack size? How do we account for architectural differe
:Ted Faber <[EMAIL PROTECTED]>
:>For every strategy there's a counterstrategy.
:exactly: the disappointing thing about this whole thread is there's been
:little discussion of implementing a (tunable) policy how to handle the
:situation when resource shortage materialises.
:
:Overcommitment can be
:Our IMAP server routinely show a footprint of about 1MB private storage.
:This is constant for most operations. However, when you get into doing
:SEARCH and SORT, there are certain cases where we need memory, sometimes
:a *lot* of memory.
:
:Your proposal is that my *well behaved* application sho
Sergey Babkin wrote:
>
> > It would be nice to have a way to indicate that, a la SIGDANGER.
>
> Another option may be to add something like "importance classes".
> Suppose we assign an one-byte "importance level" to each process.
> When we get out of swap we start killing processes with the lowe
Jason Thorpe wrote:
>
> > > ...um, so, make the code that deals with faulting in the stack a bit smarter.
> >
> > Uh? Like what? Like overcommitting, for instance? The beauty of
> > overcommitting is that either you do it or you don't. :-)
>
> One option is to special-case overcommit the sta
Robert Elz wrote:
>
> Note that all this (large) VM I have described was filled with real data
> (except for the odd times hen innd or named had just forked), none of it
> could be overcommitted and just ignored. Whatever policy was in place,
> the physical VM resources would have run out.
In
John Nemeth wrote:
>
> } > But that isn't always the best process to have killed off...
> }
> } Sure it is. :-) Let's see...
>
> This statement is absurd. Only a comptetant admin can decide
> which process can be killed. No arbitrary decision is going to be
> correct.
We are talking abou
Garance A Drosihn wrote:
>
> >> One of my main freebsd machines is mainly here to run one
> >> process, which is a pretty good-sized process (>40meg). If
> >> I did get into a memory-shortage problem, I do *not* want
> >> that process killed, I'd want some other processes killed.
> >
> > Just siz
John Nemeth wrote:
>
> } > This is based upon your somewhat strange definition of "work". I assure
> } > you that I have run many systems which don't use overcommit, and which I
> } > quite frequently run into "out of VM" conditions, and which I can assure
> } > you, work just fine. When they
Is the reason why adb hasn't been ported to freebsd because the source is
proprietary?
If gdb should suffice for my debugging needs, how can a breakpoint be set
at a particular interrupt, or even at any interrupt? The break command
only seems to accept functions, offsets, linenumbers and addresses
lyn...@orthanc.ab.ca wrote:
> The semantics of malloc() have been defined since almost the dawn of
> time. From the current manpage:
> RETURN VALUES
> The malloc() and calloc() functions return a pointer to the allocated
> memory if successful; otherwise a NULL pointer is returned
Garance A Drosihn wrote:
>
> >> One of my main freebsd machines is mainly here to run one
> >> process, which is a pretty good-sized process (>40meg). If
> >> I did get into a memory-shortage problem, I do *not* want
> >> that process killed, I'd want some other processes killed.
> >
> > Just si
In message Wayne
Cuddy writes:
: Even though I am developing on FBSD is there a "more portable" way to do this?
No. Well, not short of execing.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Is the reason why adb hasn't been ported to freebsd because the source is
proprietary?
If gdb should suffice for my debugging needs, how can a breakpoint be set
at a particular interrupt, or even at any interrupt? The break command
only seems to accept functions, offsets, linenumbers and addresse
:For the moment I'll pretend that you honestly think that is an
:answer, and I'll note that the very same machine may have well
:over 100 processes each of which takes 1-2 meg of memory. If
:the machine hits a really-out-of-memory error, I would be much
:much happier to see all 100+ of those proce
[EMAIL PROTECTED] wrote:
> The semantics of malloc() have been defined since almost the dawn of
> time. From the current manpage:
> RETURN VALUES
> The malloc() and calloc() functions return a pointer to the allocated
> memory if successful; otherwise a NULL pointer is returned.
On Thu, 15 Jul 1999, Harold Gutch wrote:
> On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote:
> > We don't _need_ pidentd anymore. It will load down a system more than
> > the inetd's implementation of ident will. Therefore, pidentd should be
> > phased out. Other than that, pidentd
In message <[EMAIL PROTECTED]> Wayne Cuddy
writes:
: Even though I am developing on FBSD is there a "more portable" way to do this?
No. Well, not short of execing.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
At 3:18 PM -0700 7/14/99, Matthew Dillon wrote:
>This conversation is getting silly. Do you actually believe
>that an operating system can magically protect itself 100%
>from armloads of hostile users?
>
>Give me a break. You people are crazy. If you have something
>worthwhil
:For the moment I'll pretend that you honestly think that is an
:answer, and I'll note that the very same machine may have well
:over 100 processes each of which takes 1-2 meg of memory. If
:the machine hits a really-out-of-memory error, I would be much
:much happier to see all 100+ of those proc
On Thu, 15 Jul 1999, Harold Gutch wrote:
> On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote:
> > We don't _need_ pidentd anymore. It will load down a system more than
> > the inetd's implementation of ident will. Therefore, pidentd should be
> > phased out. Other than that, pident
Garance A Drosihn wrote:
>
> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> But that isn't always the best process to have kil
At 3:18 PM -0700 7/14/99, Matthew Dillon wrote:
>This conversation is getting silly. Do you actually believe
>that an operating system can magically protect itself 100%
>from armloads of hostile users?
>
>Give me a break. You people are crazy. If you have something
>worthwhi
On 1999/07/14 at 11:17pm +0900, "Daniel C. Sobral" wrote:
>Ladavac Marino wrote:
>>
>> This topic has been trashed to death a few months ago. There is no
>> win-win situation in presence of processes which allocate a lot of memory
>> without actually using it (read: your typical FORTRAN l
Hi,
I have some minor probem with my CMI8330 chip based integrated sound
card on m726 motherboard.
Here's the URL where you can find how to fix it:
http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz
= cut here =
Thank you very much for your problem report.
It has the
> :Returning NULL isn't an error, it's an indication that there is no more
> :memory. Don't think if it as an error, think of it as a hint.
>
> It's only a hint if it is returned due to the process resource limit
> being hit. If it is returned due to the system running out of swap,
>
:
:Returning NULL isn't an error, it's an indication that there is no more
:memory. Don't think if it as an error, think of it as a hint.
It's only a hint if it is returned due to the process resource limit
being hit. If it is returned due to the system running out of swap,
it would
Garance A Drosihn wrote:
>
> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> But that isn't always the best process to have ki
> :Most of the work we've done wouldn't allow this, especially if we were
> :using an OS like FreeBSD with a fairly long bootup time. Especially if
> :it can be avoided.
> :
> :Yes, we could (and did) do our own memory management, but it seems to me
> :that the kernel has alot more information ava
:
:Most of the work we've done wouldn't allow this, especially if we were
:using an OS like FreeBSD with a fairly long bootup time. Especially if
:it can be avoided.
:
:Yes, we could (and did) do our own memory management, but it seems to me
:that the kernel has alot more information available to
> In article
> you write:
> >>delayed ack sounds interesting
> >
> >Turning that off disables TCP slow-start. It's a huge performance
> >booster for things like SMB service, where you have lots of short-lived
> >TCP connections on a local net.
>
> Mike probably already knows this, but
> :> > Quite true. In the embedded world we preallocate memory and shape
> :> > the programs to what is available in the system. But if we run out
> :> > of memory we usually panic and reboot - because the code is designed
> :> > to NOT run out of memory and thus running out of me
On 1999/07/14 at 11:17pm +0900, "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
>Ladavac Marino wrote:
>>
>> This topic has been trashed to death a few months ago. There is no
>> win-win situation in presence of processes which allocate a lot of memory
>> without actually using it (read: yo
:> >
:> > Quite true. In the embedded world we preallocate memory and shape
:> > the programs to what is available in the system. But if we run out
:> > of memory we usually panic and reboot - because the code is designed
:> > to NOT run out of memory and thus running out of memo
On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote:
> On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote:
> > With that in mind, how about this patch (in conjunction with the patch to
> > login.conf in the original PR, which just updates a comment)?
>
> This looks much better. :-)
C
:
:One option is to special-case overcommit the stack. Another is to
:set the default stack limits to something more reasonable on a system
:where overcommit is disabled.
:
:-- Jason R. Thorpe
Try setting all the resource limits to something reasonable on general
principles. It
[ Trimmed CC list a bit ]
> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a scheme
On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote:
> We don't _need_ pidentd anymore. It will load down a system more than
> the inetd's implementation of ident will. Therefore, pidentd should be
> phased out. Other than that, pidentd should be using
> http://www.FreeBSD.org/~green/f
Hi,
I have some minor probem with my CMI8330 chip based integrated sound
card on m726 motherboard.
Here's the URL where you can find how to fix it:
http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz
= cut here =
Thank you very much for your problem report.
It has th
On Tue, Jul 13, 1999 at 05:12:30PM -0700, Matthew Dillon wrote:
> Ok, I will be more specific.
>
> Under FreeBSD-STABLE *AND* FreeBSD-CURRENT, FreeBSD allocates metadata
> structures that scale to the amount of swap space assigned to the system.
> However, it is not *precisely* the
On Thu, 15 Jul 1999 01:59:12 +0900
"Daniel C. Sobral" wrote:
> > That's why you make it a switch. No, really, you *can* just make it
> > a switch.
>
> So, enlighten me, please... how do you switch it in NetBSD?
When the code to do it is implemented (not that hard, really, and it is
in th
On Thu, Jul 08, 1999 at 10:22:47PM +0100, Nik Clayton wrote:
> Tim Singletary has written some man pages for the dbm_* functions in libc,
> which are currently undocumented -- we know they are written in terms
> of dbopen(), but it's nice to have them documented anyway.
>
> Could anyone who knows
On Thu, 15 Jul 1999 01:52:11 +0900
"Daniel C. Sobral" wrote:
> > ...um, so, make the code that deals with faulting in the stack a bit
> > smarter.
>
> Uh? Like what? Like overcommitting, for instance? The beauty of
> overcommitting is that either you do it or you don't. :-)
One option i
On Wed, 14 Jul 1999 12:43:07 +
Niall Smart wrote:
> Perhaps it could be an additional flag to mmap, in this way
> people wishing to run an overcommited system could do so
> but those writing programs which must not overcommit for
> certain memory allocations could ensure they did not do
> :Returning NULL isn't an error, it's an indication that there is no more
> :memory. Don't think if it as an error, think of it as a hint.
>
> It's only a hint if it is returned due to the process resource limit
> being hit. If it is returned due to the system running out of swap,
>
:
:Returning NULL isn't an error, it's an indication that there is no more
:memory. Don't think if it as an error, think of it as a hint.
It's only a hint if it is returned due to the process resource limit
being hit. If it is returned due to the system running out of swap,
it woul
In message <19990714185101.09...@goatsucker.org> Scott Mitchell writes:
: Ugh. In that case, can someone back out Poul-Henning's changes to the
: if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it
: from working. At least that way only my code will be bogus :-) Believe
: me
:On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
: John Baldwin wrote:
:
: > What does that have to do with overcommit? I student administrate a
undergrad
: > CS lab at a university, and when student's programs misbehaved, they
generate a
: > fault and are killed. The only machines that reboot on us
:
:> Also, your named is badly misconfigured if it grows to 130MB. We never
:> allow ours to grow past 30MB.
:
:How do you know what kind of name server configuration kre is running?
:Here's an example of a name server running *non-recursive*, serving
:11.500 zones:
:
: PID USERNAME PRI
> :Most of the work we've done wouldn't allow this, especially if we were
> :using an OS like FreeBSD with a fairly long bootup time. Especially if
> :it can be avoided.
> :
> :Yes, we could (and did) do our own memory management, but it seems to me
> :that the kernel has alot more information av
:
:Most of the work we've done wouldn't allow this, especially if we were
:using an OS like FreeBSD with a fairly long bootup time. Especially if
:it can be avoided.
:
:Yes, we could (and did) do our own memory management, but it seems to me
:that the kernel has alot more information available to
> In article [EMAIL PROTECTED]> you
>write:
> >>delayed ack sounds interesting
> >
> >Turning that off disables TCP slow-start. It's a huge performance
> >booster for things like SMB service, where you have lots of short-lived
> >TCP connections on a local net.
>
> Mike probably alrea
> :> > Quite true. In the embedded world we preallocate memory and shape
> :> > the programs to what is available in the system. But if we run out
> :> > of memory we usually panic and reboot - because the code is designed
> :> > to NOT run out of memory and thus running out of m
:> >
:> > Quite true. In the embedded world we preallocate memory and shape
:> > the programs to what is available in the system. But if we run out
:> > of memory we usually panic and reboot - because the code is designed
:> > to NOT run out of memory and thus running out of mem
On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote:
> On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote:
> > With that in mind, how about this patch (in conjunction with the patch to
> > login.conf in the original PR, which just updates a comment)?
>
> This looks much better. :-)
[ Trimmed CC list a bit ]
> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a schem
:
:One option is to special-case overcommit the stack. Another is to
:set the default stack limits to something more reasonable on a system
:where overcommit is disabled.
:
:-- Jason R. Thorpe <[EMAIL PROTECTED]>
Try setting all the resource limits to something reasonable on general
On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote:
> We don't _need_ pidentd anymore. It will load down a system more than
> the inetd's implementation of ident will. Therefore, pidentd should be
> phased out. Other than that, pidentd should be using
> http://www.FreeBSD.org/~green/
On Tue, Jul 13, 1999 at 05:12:30PM -0700, Matthew Dillon wrote:
> Ok, I will be more specific.
>
> Under FreeBSD-STABLE *AND* FreeBSD-CURRENT, FreeBSD allocates metadata
> structures that scale to the amount of swap space assigned to the system.
> However, it is not *precisely* th
On Thu, 15 Jul 1999 01:59:12 +0900
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > That's why you make it a switch. No, really, you *can* just make it
> > a switch.
>
> So, enlighten me, please... how do you switch it in NetBSD?
When the code to do it is implemented (not that hard, rea
On Thu, Jul 08, 1999 at 10:22:47PM +0100, Nik Clayton wrote:
> Tim Singletary has written some man pages for the dbm_* functions in libc,
> which are currently undocumented -- we know they are written in terms
> of dbopen(), but it's nice to have them documented anyway.
>
> Could anyone who knows
On Thu, 15 Jul 1999 01:52:11 +0900
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > ...um, so, make the code that deals with faulting in the stack a bit smarter.
>
> Uh? Like what? Like overcommitting, for instance? The beauty of
> overcommitting is that either you do it or you don't. :-)
On Wed, 14 Jul 1999 12:43:07 +
Niall Smart <[EMAIL PROTECTED]> wrote:
> Perhaps it could be an additional flag to mmap, in this way
> people wishing to run an overcommited system could do so
> but those writing programs which must not overcommit for
> certain memory allocations could en
> Also, your named is badly misconfigured if it grows to 130MB. We never
> allow ours to grow past 30MB.
How do you know what kind of name server configuration kre is running?
Here's an example of a name server running *non-recursive*, serving
11.500 zones:
PID USERNAME PRI NICE SIZE
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
John Baldwin wrote:
> What does that have to do with overcommit? I student administrate a
> undergrad
> CS lab at a university, and when student's programs misbehaved, they
> generate a
> fault and are killed. The only machines that reboot on us
In message <[EMAIL PROTECTED]> Scott Mitchell writes:
: Ugh. In that case, can someone back out Poul-Henning's changes to the
: if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it
: from working. At least that way only my code will be bogus :-) Believe
: me, I know it's ugl
1 - 100 of 261 matches
Mail list logo
