uations where errno
> had to be cleared before calling some system routine (but I don't
> think it was read, and I am sure it wasn't on freebsd).
Ahem, I'm not sure what that's got to do with swap overcommit, but
anything to distract this thread is a good thing ;)
The cor
uations where errno
> had to be cleared before calling some system routine (but I don't
> think it was read, and I am sure it wasn't on freebsd).
Ahem, I'm not sure what that's got to do with swap overcommit, but
anything to distract this thread is a good thing ;)
The cor
On Fri, 16 Jul 1999, Daniel C. Sobral wrote:
> Technical follow-up:
>
> Contrary to what I previously said, a number of tests reveal that
> Solaris, indeed, does not overcommit. All non-read only segments,
Neither does HP/UX 10.x. (Haven't got an 11 box handy to check.)
The memory allocation pr
On Fri, 16 Jul 1999, Daniel C. Sobral wrote:
> Technical follow-up:
>
> Contrary to what I previously said, a number of tests reveal that
> Solaris, indeed, does not overcommit. All non-read only segments,
Neither does HP/UX 10.x. (Haven't got an 11 box handy to check.)
The memory allocation p
Can we kill this thread already? This resolves nothing. The only good
to come of this is all of the nice doc-proj input Matt is providing
(and providing well, I might add.)
There is no point that hasn't been rehashed a dozen times over, and
you (the ones who want overcommitting turned off) are not
:> I'm sorry, but when you write code for a safety related system you
:> do not dynamically allocate memory at all. It's all essentially static.
:> There is no issue with the memory resource. Besides, none of the BSD's
are
:> certified for any of that stuff that I know of.
:
:Som
Can we kill this thread already? This resolves nothing. The only good
to come of this is all of the nice doc-proj input Matt is providing
(and providing well, I might add.)
There is no point that hasn't been rehashed a dozen times over, and
you (the ones who want overcommitting turned off) are no
> I'm sorry, but when you write code for a safety related system you
> do not dynamically allocate memory at all. It's all essentially static.
> There is no issue with the memory resource. Besides, none of the BSD's
> are
> certified for any of that stuff that I know of.
Sometim
On Fri, 16 Jul 1999, Matthew Dillon wrote:
>
>: Well, NetBSD is slated to be used in the 'Space Acceleration
>: Measurement System II', measuring the microgravity environment on
>: the International Space Station using a distributed system based
>: on several NetBSD/i386 boxes.
: Well, NetBSD is slated to be used in the 'Space Acceleration
: Measurement System II', measuring the microgravity environment on
: the International Space Station using a distributed system based
: on several NetBSD/i386 boxes.
:
: Sometimes your 'what-if' senarios
:> I'm sorry, but when you write code for a safety related system you
:> do not dynamically allocate memory at all. It's all essentially static.
:> There is no issue with the memory resource. Besides, none of the BSD's are
:> certified for any of that stuff that I know of.
:
:Som
On Fri, 16 Jul 1999, Matthew Dillon wrote:
> I'm sorry, but when you write code for a safety related system you
> do not dynamically allocate memory at all. It's all essentially static.
> There is no issue with the memory resource. Besides, none of the BSD's
> are
> certified fo
> I'm sorry, but when you write code for a safety related system you
> do not dynamically allocate memory at all. It's all essentially static.
> There is no issue with the memory resource. Besides, none of the BSD's are
> certified for any of that stuff that I know of.
Sometimes
On Fri, 16 Jul 1999, Matthew Dillon wrote:
>
>: Well, NetBSD is slated to be used in the 'Space Acceleration
>: Measurement System II', measuring the microgravity environment on
>: the International Space Station using a distributed system based
>: on several NetBSD/i386 boxes
At 9:52 PM -0700 7/15/99, Matthew Dillon wrote:
>:> ... How many programmers bother to even *clear* errno before
>:> making these calls (since some system calls do not set errno
>:
>:> if it already non-zero). Virtually
:
:For those who wish to develop code for safety related systems that is
:not good enough. They have to prove that all code can handle the
:degradation
:of resources gracefully. Such code relies on guaranteed memory
:allocations
:or in the very least warnings of memory shortage and prioritized
:al
: Well, NetBSD is slated to be used in the 'Space Acceleration
: Measurement System II', measuring the microgravity environment on
: the International Space Station using a distributed system based
: on several NetBSD/i386 boxes.
:
: Sometimes your 'what-if' senarios
On Fri, 16 Jul 1999, Matthew Dillon wrote:
> I'm sorry, but when you write code for a safety related system you
> do not dynamically allocate memory at all. It's all essentially static.
> There is no issue with the memory resource. Besides, none of the BSD's are
> certified for
At 9:52 PM -0700 7/15/99, Matthew Dillon wrote:
>:> ... How many programmers bother to even *clear* errno before
>:> making these calls (since some system calls do not set errno
>:
>:> if it already non-zero). Virtuall
:
:For those who wish to develop code for safety related systems that is
:not good enough. They have to prove that all code can handle the
:degradation
:of resources gracefully. Such code relies on guaranteed memory
:allocations
:or in the very least warnings of memory shortage and prioritized
:a
"Daniel C. Sobral" wrote:
> > It would be nice to have a way to indicate that, a la SIGDANGER.
>
> Ok, everybody is avoiding this, so I'll comment. Yes, this would be
> interesting, and a good implementation will very probably be
> committed. *BUT*, this is not as useful as it seems. Since the
"Daniel C. Sobral" wrote:
> > It would be nice to have a way to indicate that, a la SIGDANGER.
>
> Ok, everybody is avoiding this, so I'll comment. Yes, this would be
> interesting, and a good implementation will very probably be
> committed. *BUT*, this is not as useful as it seems. Since the
Patrick Welche wrote:
>
> students != hostile users
We obviously have known different students... :-)
> Making mistakes is part of learning.
A hostile user is one which will act in a non-friendly manner.
Whether intentionaly or not is irrelevant from the point of view of
the administrator, as f
Matthew Dillon wrote:
>
> :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 kil
Matthew Dillon wrote:
>
> Something is weird here. If the solaris people are using a
> SWAPSIZE + REALMEM VM model, they have to allow the
> allocated + reserved space go +REALMEM bytes over available swap
> space. If not they are using only a SWAPSIZE VM model.
I did not check
Patrick Welche wrote:
>
> students != hostile users
We obviously have known different students... :-)
> Making mistakes is part of learning.
A hostile user is one which will act in a non-friendly manner.
Whether intentionaly or not is irrelevant from the point of view of
the administrator, as
Matthew Dillon wrote:
>
> :On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
> : John Baldwin <[EMAIL PROTECTED]> 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
> : > fau
[cc: list trimmed]
On Thu, 15 Jul 1999 lyn...@orthanc.ab.ca wrote:
> > In that scenario, the 512MB of swap I assigned to this machine would be
> > dangerously low.
>
> With 13GB disks available for a couple of hundred bucks, my machines aren't
> going to run out of swap space any time s
Matthew Dillon wrote:
>
> Something is weird here. If the solaris people are using a
> SWAPSIZE + REALMEM VM model, they have to allow the
> allocated + reserved space go +REALMEM bytes over available swap
> space. If not they are using only a SWAPSIZE VM model.
I did not check
[cc: list trimmed]
On Thu, 15 Jul 1999 [EMAIL PROTECTED] wrote:
> > In that scenario, the 512MB of swap I assigned to this machine would be
> > dangerously low.
>
> With 13GB disks available for a couple of hundred bucks, my machines aren't
> going to run out of swap space any time soo
On Thu, Jul 15, 1999 at 09:57:31PM -0700, Matthew Dillon wrote:
> Something is weird here. If the solaris people are using a
> SWAPSIZE + REALMEM VM model, they have to allow the
> allocated + reserved space go +REALMEM bytes over available swap
> space. If not they are using o
On Thu, Jul 15, 1999 at 09:57:31PM -0700, Matthew Dillon wrote:
> Something is weird here. If the solaris people are using a
> SWAPSIZE + REALMEM VM model, they have to allow the
> allocated + reserved space go +REALMEM bytes over available swap
> space. If not they are using
> > No, wait, I got that wrong I think.
> >
> > Oh yah, I remember now. Hmm. How odd. I came across a case where
> > read() could return -1 and not set errno properly if errno
> > was already set, but a perusal of the kernel code seems to indicate
> > that this can't happen.
> :> The are dozens of libc routines which call malloc internally and
> return
> :> allocated storage. strdup(), opendir(), fopen(), setvbuf(),
> asprintf(),
> :> and so forth. Dozens. And while we might check some of these for
> NULL,
> :> we don't check them all, and the o
:Technical follow-up:
:
:Contrary to what I previously said, a number of tests reveal that
:Solaris, indeed, does not overcommit. All non-read only segments,
:and all malloc()ed memory is reserved upon exec() or fork(), and the
:reserved memory is not allowed to exceed the total memory. It makes
:
:> The are dozens of libc routines which call malloc internally and return
:> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
:> and so forth. Dozens. And while we might check some of these for NULL,
:> we don't check them all, and the ones we do check w
> > No, wait, I got that wrong I think.
> >
> > Oh yah, I remember now. Hmm. How odd. I came across a case where
> > read() could return -1 and not set errno properly if errno
> > was already set, but a perusal of the kernel code seems to indicate
> > that this can't happen
Technical follow-up:
Contrary to what I previously said, a number of tests reveal that
Solaris, indeed, does not overcommit. All non-read only segments,
and all malloc()ed memory is reserved upon exec() or fork(), and the
reserved memory is not allowed to exceed the total memory. It makes
extensiv
> :> The are dozens of libc routines which call malloc internally and return
> :> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
> :> and so forth. Dozens. And while we might check some of these for NULL,
> :> we don't check them all, and the ones we d
:Technical follow-up:
:
:Contrary to what I previously said, a number of tests reveal that
:Solaris, indeed, does not overcommit. All non-read only segments,
:and all malloc()ed memory is reserved upon exec() or fork(), and the
:reserved memory is not allowed to exceed the total memory. It makes
:> The are dozens of libc routines which call malloc internally and return
:> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
:> and so forth. Dozens. And while we might check some of these for NULL,
:> we don't check them all, and the ones we do check
On Thu, 15 Jul 1999, Matthew Dillon wrote:
>
> The are dozens of libc routines which call malloc internally and return
> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
> and so forth. Dozens. And while we might check some of these for NULL,
> we don't
Technical follow-up:
Contrary to what I previously said, a number of tests reveal that
Solaris, indeed, does not overcommit. All non-read only segments,
and all malloc()ed memory is reserved upon exec() or fork(), and the
reserved memory is not allowed to exceed the total memory. It makes
extensi
:> In that scenario, the 512MB of swap I assigned to this machine would be
:> dangerously low.
:
:With 13GB disks available for a couple of hundred bucks, my machines aren't
:going to run out of swap space any time soon, even if I commit to disk.
:
:All I want for Christmas is a knob to di
:> fail, generally speaking.
:
:Is this really the case? I'm pretty sure I've _never_ ignored the
:possibility of a NULL return from malloc, and I've been using it
:for nearly 20 years. I usually print a message and exit, but I
:never ignore it. I thought that was pretty standard practise.
:
:Th
On Thu, 15 Jul 1999, Matthew Dillon wrote:
>
> The are dozens of libc routines which call malloc internally and return
> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
> and so forth. Dozens. And while we might check some of these for NULL,
> we don'
> And what I'm pretty sure the majority of the readers on this list want
> is for those of you who really think it's necessary to do it yourselves.
>
> What? Nobody who wants to disable the policy knows how to do it? Hmmm, I
> wonder whether that's significant...
Sheldon, if you can't contribute
:> In that scenario, the 512MB of swap I assigned to this machine would be
:> dangerously low.
:
:With 13GB disks available for a couple of hundred bucks, my machines aren't
:going to run out of swap space any time soon, even if I commit to disk.
:
:All I want for Christmas is a knob to d
:> fail, generally speaking.
:
:Is this really the case? I'm pretty sure I've _never_ ignored the
:possibility of a NULL return from malloc, and I've been using it
:for nearly 20 years. I usually print a message and exit, but I
:never ignore it. I thought that was pretty standard practise.
:
:T
> And what I'm pretty sure the majority of the readers on this list want
> is for those of you who really think it's necessary to do it yourselves.
>
> What? Nobody who wants to disable the policy knows how to do it? Hmmm, I
> wonder whether that's significant...
Sheldon, if you can't contribute
> All I want for Christmas is a knob to disable overcommit.
And what I'm pretty sure the majority of the readers on this list want
is for those of you who really think it's necessary to do it yourselves.
What? Nobody who wants to disable the policy knows how to do it? Hmmm,
Andrew Reilly wrote:
>
> On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote:
> > Actually, applications are written assuming that malloc() will not
> > fail, generally speaking.
>
> Is this really the case? I'm pretty sure I've _never_ ignored the
> possibility of a NULL return fro
On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote:
> Actually, applications are written assuming that malloc() will not
> fail, generally speaking.
Is this really the case? I'm pretty sure I've _never_ ignored the
possibility of a NULL return from malloc, and I've been using it
for
On Thu, 15 Jul 1999 17:53:52 CST, lyn...@orthanc.ab.ca wrote:
> All I want for Christmas is a knob to disable overcommit.
And what I'm pretty sure the majority of the readers on this list want
is for those of you who really think it's necessary to do it yourselves.
What? Nobody who wants to di
> All I want for Christmas is a knob to disable overcommit.
And what I'm pretty sure the majority of the readers on this list want
is for those of you who really think it's necessary to do it yourselves.
What? Nobody who wants to disable the policy knows how to do it? Hmmm,
> In that scenario, the 512MB of swap I assigned to this machine would be
> dangerously low.
With 13GB disks available for a couple of hundred bucks, my machines aren't
going to run out of swap space any time soon, even if I commit to disk.
All I want for Christmas is a knob to disable ov
Andrew Reilly wrote:
>
> On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote:
> > Actually, applications are written assuming that malloc() will not
> > fail, generally speaking.
>
> Is this really the case? I'm pretty sure I've _never_ ignored the
> possibility of a NULL return fr
Here is what I get from one of BEST's mail & www proxy machines.
~dillon/br adds the object size's together. 'swap' and 'default'
objects refers to unbacked VM objects - and none of the processes running
fork shared unbacked objects so we don't have to worry about that. The
'
On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote:
> Actually, applications are written assuming that malloc() will not
> fail, generally speaking.
Is this really the case? I'm pretty sure I've _never_ ignored the
possibility of a NULL return from malloc, and I've been using it
fo
On Thu, 15 Jul 1999 17:53:52 CST, [EMAIL PROTECTED] wrote:
> All I want for Christmas is a knob to disable overcommit.
And what I'm pretty sure the majority of the readers on this list want
is for those of you who really think it's necessary to do it yourselves.
What? Nobody who wants to disa
> In that scenario, the 512MB of swap I assigned to this machine would be
> dangerously low.
With 13GB disks available for a couple of hundred bucks, my machines aren't
going to run out of swap space any time soon, even if I commit to disk.
All I want for Christmas is a knob to disable o
> If this is correct, then solaris is using a VMSPACE = SWAPSPACE
> model. FreeBSD uses a VMSPACE = SWAPSPACE + REALMEM model.
AFAIK it has been stated quite explicitly by the Solaris folks that
Solaris 2.x uses VMSPACE = SWAPSPACE + REALMEM. This is *different*
from SunOS 4.1.x.
Steinar
In article
you
write:
>::-s Print summary information about total swap
>:: space usage and availability:
>::
>:: allocated The total amount of swap space
>:: (in 1024-byte blocks)
>::
:Before program start:
:total: 2k bytes allocated + 4792k reserved = 24792k used, 191048k available
:
:After malloc, before touch:
:total: 18756k bytes allocated + 37500k reserved = 56256k used, 159580k
available
:
:After malloc + touch:
:total: 52804k bytes allocated + 4852k reserved = 57656
Here is what I get from one of BEST's mail & www proxy machines.
~dillon/br adds the object size's together. 'swap' and 'default'
objects refers to unbacked VM objects - and none of the processes running
fork shared unbacked objects so we don't have to worry about that. The
> If this is correct, then solaris is using a VMSPACE = SWAPSPACE
> model. FreeBSD uses a VMSPACE = SWAPSPACE + REALMEM model.
AFAIK it has been stated quite explicitly by the Solaris folks that
Solaris 2.x uses VMSPACE = SWAPSPACE + REALMEM. This is *different*
from SunOS 4.1.x.
Steina
In article [EMAIL PROTECTED]> you
write:
>::-s Print summary information about total swap
>:: space usage and availability:
>::
>:: allocated The total amount of swap space
>:: (in 1024-byte bloc
:Before program start:
:total: 2k bytes allocated + 4792k reserved = 24792k used, 191048k available
:
:After malloc, before touch:
:total: 18756k bytes allocated + 37500k reserved = 56256k used, 159580k available
:
:After malloc + touch:
:total: 52804k bytes allocated + 4852k reserved = 57656
On Wed, 14 Jul 1999, John Nemeth wrote:
> On Jul 15, 2:40am, "Daniel C. Sobral" wrote:
> } 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 deman
On Wed, 14 Jul 1999, John Nemeth wrote:
> On Jul 15, 2:40am, "Daniel C. Sobral" wrote:
> } 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 dema
::-s Print summary information about total swap
:: space usage and availability:
::
:: allocated The total amount of swap space
:: (in 1024-byte blocks)
:: currentl
:"pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page:
:
::-s Print summary information about total swap
:: space usage and availability:
::
:: allocated The total amount of swap space
:: (
> On Thu, 15 Jul 1999 11:09:01 -0700 (PDT),
Matthew Dillon said:
> Umm... how are you getting the reserved numbers?
"pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page:
:-s Print summary information about total swap
: space
:Both Dillon and Sobral mistakenly claimed that "Solaris overcommits",
:this fact seems to be somewhat suggestive.
:
:And also, the followings are allocated memory and reserved memory
:in my environment. (This table also includes Eduardo's example)
:
: SunOS allocated reservedtotal tot
> On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
>> Uh... like any modern unix, Solaris overcommits.
> On Thu, 15 Jul 1999 08:46:36 -0700 (PDT),
"Eduardo E. Horvath" said:
> Where do you guys get this misinformation?
:
> Note the `19464k reserved'; that space has been reserve
::-s Print summary information about total swap
:: space usage and availability:
::
:: allocated The total amount of swap space
:: (in 1024-byte blocks)
:: current
:"pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page:
:
::-s Print summary information about total swap
:: space usage and availability:
::
:: allocated The total amount of swap space
::
> On Thu, 15 Jul 1999 11:09:01 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> Umm... how are you getting the reserved numbers?
"pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page:
:-s Print summary information about total swap
:
:Both Dillon and Sobral mistakenly claimed that "Solaris overcommits",
:this fact seems to be somewhat suggestive.
:
:And also, the followings are allocated memory and reserved memory
:in my environment. (This table also includes Eduardo's example)
:
: SunOS allocated reservedtotal to
> On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
>> Uh... like any modern unix, Solaris overcommits.
> On Thu, 15 Jul 1999 08:46:36 -0700 (PDT),
"Eduardo E. Horvath" <[EMAIL PROTECTED]> said:
> Where do you guys get this misinformation?
:
> Note the `19464k reserved'; that sp
At 6:29 PM -0700 7/14/99, Matthew Dillon wrote:
>If 1G isn't enough, spend another $30 and throw 2G of swap
>online. Or perhaps dedicate an entire $150 disk and throw
>6+ GB of swap online.
>
>The equivalent setup using a non-overcommit model would require
>considerably more sw
lyn...@orthanc.ab.ca wrote:
>
> All of the arguments I've seen so far assume that one process is
> running off and grabbing all the available memory. That may be
> the most likely scenario, but it's most certainly not the *only*
> scenario. What if you have a whole bunch of "middle sized" processe
Danny Thomas wrote:
>
> >Killing the biggest is simple to implement and usually right.
> ... but some people don't want that policy, at least on some of their
> systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously
> absent from discussion, which might have taken things into
At 6:29 PM -0700 7/14/99, Matthew Dillon wrote:
>If 1G isn't enough, spend another $30 and throw 2G of swap
>online. Or perhaps dedicate an entire $150 disk and throw
>6+ GB of swap online.
>
>The equivalent setup using a non-overcommit model would require
>considerably more s
[EMAIL PROTECTED] wrote:
>
> All of the arguments I've seen so far assume that one process is
> running off and grabbing all the available memory. That may be
> the most likely scenario, but it's most certainly not the *only*
> scenario. What if you have a whole bunch of "middle sized" processes
Danny Thomas wrote:
>
> >Killing the biggest is simple to implement and usually right.
> ... but some people don't want that policy, at least on some of their
> systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously
> absent from discussion, which might have taken things into
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 th
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
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
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
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
:
: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
: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
1 - 100 of 182 matches
Mail list logo