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
:
: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
:
: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
: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
:
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
: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
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
> 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
> 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,
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
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, 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
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
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
: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
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
>
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
: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
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
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
: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
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
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
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
: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
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
: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
: > fault and are killed. The only machines
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
> fault and are killed. The only machines that
1 - 100 of 152 matches
Mail list logo
