Oliver,
I am sending you this email outside the list, because I think that
enough emails have been sent regarding my message.
Now to your statements:
On 18/12/2010 11:47 πμ, Oliver Fromme wrote:
George Mamalakis wrote:
> Oliver, thanx for your comments. I know it is difficult to choose which
> process to kill and how to be "fair" during such a killing procedure.
> Nevertheless, I would assume that all non-root processes would have
> higher priority to get killed, and that root's processes would get
> killed last.
The owner of the process is not taken into consideration,
because the "run-away" process causing the memory shortage
may as well be a root-owned process. In such a situation,
if root processes were exempt from killing, the system
would deadlock and require a hard reboot. Killing the
root-owned process is the lesser of two evils.
As I explained in one of my previous emails, I expected that root
processes would have *lower priority* than non-root processes; I never
implied that root processes shouldn't get killed, it would be irrational
to say so.
As I already explained, there is a process flag that root-
owned processes can set for themselves, preventing the
kernel from killing them in low-memory situations. See
the description of the MADV_PROTECT flag in the madvise(2)
manual page. For example, cron(8) and sshd(8) make use of
this, so they will not be killed. This is a better way
than simply excluding all root processes.
> I understand your comments completely, but I was just so
> surprised when I realized how easy it was for me to kill root processes
> on my system.
Only because you didn't configure resource limits. ;-)
When you're the only user on a machine, such as a desktop
box, this is usually not a big deal. But in all other
cases it's strongly recommended to set resource limits,
in particular for shell users and for server processes.
Without any resource limits, a normal user can starve the
system and take it down. This is an old and well-known
problem for all UNIX systems (and most non-UNIX systems,
too, I guess). You certainly didn't discover any new
problem.
If you're concerned, configure resource limits. Period.
As I stated in my first message (if I recall correctly), all this
happened because I didn't configure my rlimits (it's my laptop). Of
course I am aware of resource limits, and I configure them on most of
the servers I administer for the last 12 years (I've seen my vmstat
showing 500+ processes in blocked-by-io state, and the system wouldn't
hang..:)). I never implied to have discovered anything new, and
especially something regarding resource limits. All my enthusiasm was
caused firstly due to fbsd's memory allocation algorithm (I never knew
the system would assume that it could allocate 500+GB of memory, and the
replies on this issue where very enlightening for me), and secondly due
to fbsd's algorithm on process killing when memory has been starved.
Certainly, I was not surprised by the fact that my system was out of
memory...exceeding my system's memory limits was my experiment in the
first place!
Anyway, thanx again for your answer and all your pointers (MADV_PROTECT,
etc), and I think there is no need to get angry about my emails. As I
initially stated, my questions where rhetorical, and no answers where
needed. I trusted that there should be a good reason behind this
behavior...Some of you answered on the list and I just replied with my
opinion. Nothing more, nothing less.
Have a nice day and kind regards,
mamalos
--
George Mamalakis
IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)
Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki
phone number : +30 (2310) 994379
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
