lkml.org 
[lkml]   [1998]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: A true story of a crash.
Date
Matt Agler writes:
> On Sat, 15 Aug 1998, Albert D. Cahalan wrote:

>> How do you _not_ let every last page get used? The first obvious
>> problem is overcommit, which you'd have to disable.
>
> No. When you hit 90% (or whatever, make it configurable) utilization of
> swap, you set a flag. The kernel is overcommitted all over the place, but

That is useful on a large enough machine. The 90% rule needs to
be a 2 MB rule, and small machines just don't have the spare memory.

I like it, but don't see it as a replacement for the process killer.
It won't save you from daemons gone wild, many of which will be
restarted if the kernel kills them. It also won't help a tiny machine
or a machine with the admin on vacation.

> it's ok, most processes don't use the memory. Some will, they fault on a
> nonexistant page, the kernel needs to create a page so we end up in
> do_no_page. It sees that the flag is set - oops we're running out of
> memory. It sees that the faulting process is a user process, so it logs
> it and puts it to sleep. That's it. It's a very small thing.

The definition of "user process" is the same issue faced by the
process killer. X is not a user process, even if the UID is nobody.

> The schedular ignores these sleepers while the flag is set. When we get
> memory back, the flag's reset and everything continues as normal. The
> flag will get reset as soon as the _ADMIN DECIDES_ what to do. He could
> just kill the process or add swap or whatever.
>
> Anyway, it was just an idea. If you don't like it, fine. I think I've
> made it pretty clear. Since I haven't heard any substantive arguments
> against it ("that won't work" and "I don't like it" armwaving doesn't
> count) perhaps it has some (just a wee bit) merit?

I could see it being useful on a machine that crunches numbers.
Most Linux machines do other stuff though.

How about the following steps, in order?

1. optional SIGWARN, or whatever it is AIX sends
2. optional removal from scheduler
3. optional (highly recommended) process killer
4. mandatory oops, kill everything, and reboot

For the SIGWARN, glibc could return freed memory to the OS.
(would need to be disabled for init and other critical things)

The process killer alone is simple though, and already written.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.115 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site