:
:Matthew Dillon wrote:
:
: What it all comes down to is a juxtaposition of what people believe
: is appropriate verses what people are actually willing to code up.
: I'm willing to code up my importance mechanism idea. The question is
: whether it's a good enough idea to
:Matthew Dillon wrote:
:
: How about this - add an 'importance' resource. The lower the number,
: the more likely the process will be killed if the system runs out of
: resources. We would also make fork automatically decrement the number
: by one in the child.
:
:Well, that's
Matthew Dillon wrote:
What it all comes down to is a juxtaposition of what people believe
is appropriate verses what people are actually willing to code up.
I'm willing to code up my importance mechanism idea. The question is
whether it's a good enough idea to throw into
:where SIZE was 4 MB in this case. I ran it on the console (I've got 64 MB
:of RAM and 128 MB of swap) until the swap pager went out of space and
:my huge process was eventually killed as expected. Fine. But when I ran
:it under X Window, the system eventually killed the X server (SIZE ~20
First, let me warn you that this is a often recurring thread. It has
already showed up two or three times this year alone.
Ivan wrote:
I had a look at vm_pageout.c and noticed that situations may occur where
no process can be killed. I guess that in such situations memory
allocation
On Thu, 23 Sep 1999, Daniel C. Sobral wrote:
First, let me warn you that this is a often recurring thread. It has
already showed up two or three times this year alone.
Ivan wrote:
I had a look at vm_pageout.c and noticed that situations may occur where
no process can be killed. I
On Thu, 23 Sep 1999, Daniel C. Sobral wrote:
I had a look at vm_pageout.c and noticed that situations may occur where
no process can be killed. I guess that in such situations memory
allocation requests are simply rejected ( e.g. malloc returning NULL ) .
Err... no. Malloc() does not
On Wed, 22 Sep 1999, Alfred Perlstein wrote:
Terry Lambert brought up an interesting thought from AIX (I think),
instead of killing a process, it just sleeps the requesting process
until the situation alleviates itself. Of course this can wind up
wedging an entire system, it would probably
Ivan wrote:
Of course I didn't mean that malloc() calls the pageout daemon ... I
simply meant that if no more memory space can be regained (in particular
by killing a process) then at some point memory allocations will be
refused -- or else, when does malloc() ever returns NULL ?!
When
On Wed, 22 Sep 1999, Chuck Robey wrote:
On Wed, 22 Sep 1999, Alfred Perlstein wrote:
Terry Lambert brought up an interesting thought from AIX (I think),
instead of killing a process, it just sleeps the requesting process
until the situation alleviates itself. Of course this can wind
What kind of resources are there that both cause loss of swap AND are
freed up by sleeping a process?
four things i can think of:
1) Along with 'SIGDANGER' it allows the system to fix itself.
That's another issue. Don't mix sleeping processes with SIGDANGER, they
are independant of
How about this - add an 'importance' resource. The lower the number,
the more likely the process will be killed if the system runs out of
resources. We would also make fork automatically decrement the number
by one in the child.
The default would be 1000. The sysadmin
On Wed, 22 Sep 1999, Matthew Dillon wrote:
How about this - add an 'importance' resource. The lower the number,
the more likely the process will be killed if the system runs out of
resources. We would also make fork automatically decrement the number
by one in the child.
On Wed, 22 Sep 1999, Nate Williams wrote:
Maybe, and then again, maybe not. A program is requesting memory, so
putting other processes to sleep *keeps* them from freeing up memory.
The process that is trying to use memory is put to sleep. In the
machine runs out of swap cases I have seen
Maybe, and then again, maybe not. A program is requesting memory, so
putting other processes to sleep *keeps* them from freeing up memory.
The process that is trying to use memory is put to sleep.
Then this 'rogue' process is never allowed to free up any of it's
resources, hence the
: (Matt)
: How about this - add an 'importance' resource. The lower the number,
: the more likely the process will be killed if the system runs out of
: resources. We would also make fork automatically decrement the number
: by one in the child.
:
: The default would be
On Wed, 22 Sep 1999, Matthew Dillon wrote:
: (Matt)
: How about this - add an 'importance' resource. The lower the number,
: the more likely the process will be killed if the system runs out of
: resources. We would also make fork automatically decrement the number
: by
Chuck Robey wrote:
What kind of resources are there that both cause loss of swap AND are
freed up by sleeping a process?
Any of them being consumed by short-lived processes that will run to
completion and exit while everyone else is sleeping. This assumes such
processes exist, of course.
Matthew Dillon wrote:
How about this - add an 'importance' resource. The lower the number,
the more likely the process will be killed if the system runs out of
resources. We would also make fork automatically decrement the number
by one in the child.
As far as I'm
Nate Williams wrote:
Maybe, and then again, maybe not. A program is requesting memory, so
putting other processes to sleep *keeps* them from freeing up memory.
The process that is trying to use memory is put to sleep.
Then this 'rogue' process is never allowed to free up any of
On Wed, 22 Sep 1999, Wes Peters wrote:
Chuck Robey wrote:
What kind of resources are there that both cause loss of swap AND are
freed up by sleeping a process?
Any of them being consumed by short-lived processes that will run to
completion and exit while everyone else is sleeping.
On Wed, 22 Sep 1999, Alfred Perlstein wrote:
What kind of resources are there that both cause loss of swap AND are
freed up by sleeping a process?
four things i can think of:
1) Along with 'SIGDANGER' it allows the system to fix itself.
2) Allow the operator to determine which program
Matthew Dillon wrote:
How about this - add an 'importance' resource. The lower the number,
the more likely the process will be killed if the system runs out of
resources. We would also make fork automatically decrement the number
by one in the child.
Well, that's one
On Thu, 23 Sep 1999, Daniel C. Sobral wrote:
Matthew Dillon wrote:
How about this - add an 'importance' resource. The lower the number,
the more likely the process will be killed if the system runs out of
resources. We would also make fork automatically decrement the
Hi,
I have a couple of questions about the way 'out of swap' situations are
handled in FreeBSD. Not that my system often runs out of swap, I'm just
being curious:
When the system runs out of swap space, it is supposed to kill the
'biggest' process to regain some space.
I wrote a little
:where SIZE was 4 MB in this case. I ran it on the console (I've got 64 MB
:of RAM and 128 MB of swap) until the swap pager went out of space and
:my huge process was eventually killed as expected. Fine. But when I ran
:it under X Window, the system eventually killed the X server (SIZE ~20 MB,
26 matches
Mail list logo
