public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: james <jdickens@ameritech.net>
To: Rik van Riel <riel@conectiva.com.br>
Cc: <linux-kernel@vger.kernel.org>
Subject: Ideas for the oom problem
Date: Tue, 27 Mar 2001 18:53:18 -0600	[thread overview]
Message-ID: <01032718343500.32154@friz.themagicbus.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0103271815370.26154-100000@duckman.distro.conectiva>


Hi Kernel Guru's

Here are my ideas on how too deal with the oom situation, most of these 
should be thought of stuff to do in 2.5.x kernels, because it touches a lot 
of kernel path ways,  with possible back porting 
once it is tested. 

I propose a three prong approach too this problem

Prong 1: WHAT TOO KILL 

a. don't kill any task with a uid < 100 
    
b. if uid between 100 to 500 or CAP-SYS equivalent enabled 
	set it too a lower priority, so if it is at fault it will happen slower 		   
            giving more time before the system collapses

c.  if a task is nice'd then immediately put the task too sleep, and schedule 
all code / data too be swapped out, or thrown away as appropiate. do not 
reschedule the task too continue until memory is available 

d. kill any normal user interactive tasks that is started during a memory 
crisis. 

Prong 2 WHAT TOO DO ABOUT STABILIZING THE SYSTEM 

allocate a pool of memory at system start up that is too be released to the 
memory pool when the system is in a memory crisis. This will reduce system 
swapping, and allow the system too stablize slightly

report any task asking for large pool of memory while the system is in 
oom crisis. if uid > 500 and was started from an interactive shell it should 
be killed. 

when the crisis is ended, re-adquire the memory pool for later usage. 

Prong 3 providing  information about oom crisis too user land 

create /proc/vm/oom_crisis this would be readonly file owned by root it would 
report if the system is in crisis and the uid of any process that is asking 
for large amounts of ram while the system 
is in crisis. 

create a SIGDANGER handler that is sent out too all tasks that have 
registered a handler when the kernel enters oom_kill, give these tasks a high 
priority access too system resources. 

this would enable user land programs too deal with the situation with out 
continuous polling free ram/swap. They could email/page sysadmin and user 
about the crisis and add additional swap resources and kill any know  non 
essential tasks. and probe system for possible broken tasks, such as 
netscape-common tasks not connected too netscape client, at least i have been 
known too find these when netscape crashes. 



Okay that is my idea, i am putting on my flame proof suit and getting ready 
for the flames that are sure too come my way.....



James 
kernelnewbie in training 

  parent reply	other threads:[~2001-03-28  0:30 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-27 21:29 [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated) Richard Jerrell
2001-03-27 21:18 ` Rik van Riel
2001-03-27 23:10   ` Richard Jerrell
2001-03-27 22:57     ` Rik van Riel
2001-03-28  0:53   ` james [this message]
2001-03-28  0:52     ` Ideas for the oom problem Rik van Riel
2001-03-28  1:14       ` Doug Ledford
2001-03-28  3:21         ` Rik van Riel
2001-03-28  3:41           ` Doug Ledford
2001-03-28  3:53             ` Rik van Riel
2001-03-28  1:39       ` james
2001-03-28  5:52     ` Jonathan Morton
2001-03-28  6:16       ` Disturbing news Shawn Starr
2001-03-28  6:33         ` Disturbing news.. Idea Shawn Starr
2001-04-21  0:43           ` Serious Latency problems : 2.4.4-pre5 Shawn Starr
2001-03-28  7:19         ` Disturbing news Matti Aarnio
2001-03-28  7:27           ` Shawn Starr
2001-03-28 12:08             ` Jesse Pollard
2001-03-28  5:50               ` Ben Ford
2001-03-28 12:50               ` Walter Hofmann
2001-03-28 14:04                 ` Simon Williams
2001-03-28 15:04                   ` Olivier Galibert
2001-03-28 15:49                     ` Simon Williams
2001-03-28 11:57                       ` Ben Ford
2001-03-29  8:02                         ` Helge Hafting
2001-03-28 17:51                       ` Olivier Galibert
2001-03-28 12:53               ` Keith Owens
2001-03-28 13:00               ` Russell King
2001-03-28 14:10               ` Sean Hunter
2001-03-28 15:36                 ` john slee
2001-03-28 16:18                   ` Jonathan Lundell
2001-04-02 23:10               ` Dr. Kelsey Hudson
2001-03-28 17:29             ` Horst von Brand
2001-03-28 10:00         ` Helge Hafting
2001-03-28 13:25         ` Alexander Viro
2001-03-28 14:32           ` Romano Giannetti
2001-03-28 14:57             ` Bill Rugolsky Jr.
2001-03-28 14:57             ` Alexander Viro
2001-03-28 16:14               ` Romano Giannetti
2001-03-28 14:38     ` Ideas for the oom problem Hacksaw
2001-03-28 15:56       ` Andreas Rogge
2001-03-28 23:33         ` Hacksaw
2001-03-28 23:47           ` Tim Haynes
2001-03-29  0:12             ` Hacksaw
2001-03-27 21:51 ` [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated) Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01032718343500.32154@friz.themagicbus.com \
    --to=jdickens@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox