From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sat, 10 Jun 2006 19:12:16 -0500 From: quanstro@quanstro.net To: 9fans@cse.psu.edu Subject: Re: [9fans] quantity vs. quality In-Reply-To: <448B4F88.4090101@lanl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 67afc4cc-ead1-11e9-9d60-3106f5b1d025 i think we mostly agree. i'm a little sick of trying to read code with gobs of recovery goo that may or may not ever get executed. who knows? on the other hand, you're right. if there's a way to kill the kernel by running it out of memory, then that should be fixed, if possible. no questions. it would be better for xcpu to start lining up processes for the firing squad until sufficient memory is available. - erik On Sat Jun 10 18:04:07 CDT 2006, rminnich@lanl.gov wrote: > > xcpu server is running a couple hundred processes for testing. It is > asked to do one more. It can't allocate something. > > Just dying at that point is really a bad idea, and we did find that some > of the libraries we were using would in fact do that, without coming > back to xcpu server main code with an error. That's not good behaviour > for xcpu server. It should gracefully return 'no more room' and keep > managing things; in some few cases, the library did not give us that > option. > > There are lots of cases like this, many of them in the kernel even; > would we want the kernel to just toss chunks at these times? > > I agree -- sometimes, death is the only option. But not always. > > ron