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
next prev 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