lkml.org 
[lkml]   [1998]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A true story of a crash.

Actually it doesn't sound bad, until you get to the manual intervention
part.. I admin MANY systems, and I dont log into all of them weekly much
less daily.. Sure, I could set it up to page me or something but I doubt
many processes will like getting zero cpu time for the peroid of hours it
will take me to fix the problem.. Furthermore if there is an attacker he
could just relog and attack again..

at 95% (sysctl tunable) your flag goes on and processes goto sleep, any
requests to swaped ram for nonsleeping processes get stasitfied by
swapping out chuncks of sleeping tasks into the place you are loading
from.. Things like X and daemons wont be elegiable for sleeping.

Ok, by putting things to sleep your've stopped your system from swapping
to death.. Now a reaper decides what to kill, since the system isn't
already up in flames it's got a little time to decide..

Once memory is freed things go back to normal.


On Sat, 15 Aug 1998, Matt Agler wrote:

>
> On Sat, 15 Aug 1998, Albert D. Cahalan wrote:
>
> > Matt Agler writes:
> > > On Sat, 15 Aug 1998, Albert D. Cahalan wrote:
> >
> > >>> It would be better and simpler to let the user or admin decide what to
> > >>> kill. Instead of killing a process, we should put it to sleep.
> > >>
> > >> End result: 100% memory use, 100% idle, all processes stopped.
> > >
> > > That depends on implementation. Of course, if you let every last page
> > > get used before doing anything, you're stuck.
> >
> > 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
> 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 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?
>
> -Matt
>
>
>
> -
> 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
>


-
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.059 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site