vm.swap_reserved toooooo large?

[Ronald Klop]

On Sat, 18 Dec 2010 12:52:10 +0100, George Mamalakis <mamalos at eng.auth.gr>  
wrote:

> Oliver,
>
> I am sending you this email outside the list, because I think that
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That didn't work out as you intended. :-)

> 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