Re: OOM Test Case - Failed!
On Sat, 21 Oct 2000, Rik van Riel wrote: > > The oom killer avoided killing your busy, large, root-owned > > process. Don't run gcc compiles as root. Protecting root > > processes is an explicit design goal here. > > Also: > > 1) his system pretty much continued to run > 2) since only httpd children got killed, no work >was lost The system ran, but nothing moved. No process was able to do any activity, because they were all waiting on swapped out space or waiting to use more as-of-yet unallocated virtual memory. I could verify this because one of my daemons writes one line to disk every 5 minutes. That stopped completely during this event. > (only the fact that he ran genattrtab as root screwed > up things a bit and kept the system from killing the > task -- but probably only just) If I would have known, I would have done otherwise. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Wed, 18 Oct 2000, Stephen Tweedie wrote: > On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: > > > I am very unimpressed with the current OOM killer. After 10 days of online > > time, I decided to try compiling gcc again, the very culprit that killed my > > last system using 2.4.0-test8 Friday night (to which I was unable to reset > > the system until Monday morning). > > > > root 1099 63.6 61.5 71424 18740 pts/0 R09:39 1:22 ./genattrtab > > The oom killer avoided killing your busy, large, root-owned > process. Don't run gcc compiles as root. Protecting root > processes is an explicit design goal here. Also: 1) his system pretty much continued to run 2) since only httpd children got killed, no work was lost (only the fact that he ran genattrtab as root screwed up things a bit and kept the system from killing the task -- but probably only just) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Wed, 18 Oct 2000, Stephen Tweedie wrote: On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: I am very unimpressed with the current OOM killer. After 10 days of online time, I decided to try compiling gcc again, the very culprit that killed my last system using 2.4.0-test8 Friday night (to which I was unable to reset the system until Monday morning). root 1099 63.6 61.5 71424 18740 pts/0 R09:39 1:22 ./genattrtab The oom killer avoided killing your busy, large, root-owned process. Don't run gcc compiles as root. Protecting root processes is an explicit design goal here. Also: 1) his system pretty much continued to run 2) since only httpd children got killed, no work was lost (only the fact that he ran genattrtab as root screwed up things a bit and kept the system from killing the task -- but probably only just) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Sat, 21 Oct 2000, Rik van Riel wrote: The oom killer avoided killing your busy, large, root-owned process. Don't run gcc compiles as root. Protecting root processes is an explicit design goal here. Also: 1) his system pretty much continued to run 2) since only httpd children got killed, no work was lost The system ran, but nothing moved. No process was able to do any activity, because they were all waiting on swapped out space or waiting to use more as-of-yet unallocated virtual memory. I could verify this because one of my daemons writes one line to disk every 5 minutes. That stopped completely during this event. (only the fact that he ran genattrtab as root screwed up things a bit and kept the system from killing the task -- but probably only just) If I would have known, I would have done otherwise. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
Hi, On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: > I am very unimpressed with the current OOM killer. After 10 days of online > time, I decided to try compiling gcc again, the very culprit that killed my > last system using 2.4.0-test8 Friday night (to which I was unable to reset > the system until Monday morning). > > root 1099 63.6 61.5 71424 18740 pts/0 R09:39 1:22 ./genattrtab The oom killer avoided killing your busy, large, root-owned process. Don't run gcc compiles as root. Protecting root processes is an explicit design goal here. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: > I am very unimpressed with the current OOM killer. [...] > We need to decide on a better algorithm, > albeit simple, that will alleviate this problem before 2.4.0 final comes out. We don't need to decide on one, you can provide and install your own, if your apply my oom-killer-api-patch. It's at: http://www.tu-chemnitz.de/~ioe/oom_kill_api.patch PS: Removed Linus from CC, because every change of MM has to be approved by Rik first. Added linux-mm, because it's an MM issue. PPS: We had an controversal discussion at linux-mm about this last week. So look into the archives. Regards Ingo Oeser -- Feel the power of the penguin - run [EMAIL PROTECTED] :x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: I am very unimpressed with the current OOM killer. [...] We need to decide on a better algorithm, albeit simple, that will alleviate this problem before 2.4.0 final comes out. We don't need to decide on one, you can provide and install your own, if your apply my oom-killer-api-patch. It's at: http://www.tu-chemnitz.de/~ioe/oom_kill_api.patch PS: Removed Linus from CC, because every change of MM has to be approved by Rik first. Added linux-mm, because it's an MM issue. PPS: We had an controversal discussion at linux-mm about this last week. So look into the archives. Regards Ingo Oeser -- Feel the power of the penguin - run [EMAIL PROTECTED] esc:x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
Hi, On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: I am very unimpressed with the current OOM killer. After 10 days of online time, I decided to try compiling gcc again, the very culprit that killed my last system using 2.4.0-test8 Friday night (to which I was unable to reset the system until Monday morning). root 1099 63.6 61.5 71424 18740 pts/0 R09:39 1:22 ./genattrtab The oom killer avoided killing your busy, large, root-owned process. Don't run gcc compiles as root. Protecting root processes is an explicit design goal here. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
