> :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,
> :RES ~14 MB -- the biggest RES size) instead of my big process (SIZE ~100
> :MB, RES 0K).
> :
> :My question is: Why was the X server killed ? Was it because the 'biggest'
> :process is the one with the biggest resident memory size ?
> :And if so, why not take into account the total size of processes ?
>
> The algorithm is pretty dumb. In fact, it would not be too difficult
> to actually calculate the amount of swap being used by a process and
> add that to the RSS when figuring out who to kill.
Thank you for your explanations !
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 ) .
Is there a reason why this isn't the default behavior in FreeBSD ? i.e.
why does the system always try to kill a process ?
>
> The X server wasn't killed nicely, it couldn't take you out of the
> video mode.
>
Indeed, the 'biggest' process is SIGKILLed without any prior notice. Would
it be possible to send him a nicer signal first, to let him a chance to
quit before being killed ?
A last question, to FreeBSD developpers:
After a few tests, I came to the conclusion that it's quite easy to crash
a vanilla FreeBSD system (without any per-user/per-process limits set) by
simply running it out of swap space ... (the 'kill the biggest process'
mechanism doesn't seem to always work !?)
Is this a currently addressed issue, or is it simply considered not an
issue ?
Thanks in advance for your time,
Ivan
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
