This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 19:13:51 2024 Received: from entropy.muc.muohio.edu (entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.8.8/8.8.8) with ESMTP id RAA13726 for ; Mon, 5 Oct 1998 17:31:51 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.9.0/8.8.7) with ESMTP id SAA00599; Mon, 5 Oct 1998 18:25:40 -0400 Received: by vger.rutgers.edu id <154980-9975>; Mon, 5 Oct 1998 11:01:35 -0400 Received: from ns.rnl.ist.utl.pt ([193.136.164.1]:48417 "EHLO ns.rnl.ist.utl.pt" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <154968-9975> convert rfc822-to-8bit; Mon, 5 Oct 1998 09:02:18 -0400 Received: from hal.rnl.ist.utl.pt (rcu79.rnl.ist.utl.pt [193.136.154.79]) by ns.rnl.ist.utl.pt (8.9.0/8.9.0) with ESMTP id TAA11153 for ; Mon, 5 Oct 1998 19:17:17 +0100 (WET DST) Received: (from l39801@localhost) by hal.rnl.ist.utl.pt (8.6.9/8.6.9) id TAA20528 for linux-kernel@vger.rutgers.edu; Mon, 5 Oct 1998 19:05:33 +0100 Message-Id: <19981005190529.A20518@hal.rnl.ist.utl.pt> Date: Mon, 5 Oct 1998 19:05:29 +0100 From: Carlos Morgado To: linux-kernel@vger.rutgers.edu Subject: Re: Out Of Memory in v. 2.1 References: <"z6pYs.0.Bg1.yt56s"@tequila.systemsz.cs.yale.edu> <5lvhlzdu5k.fsf@tequila.systemsz.cs.yale.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT X-Mailer: Mutt 0.93.1 In-Reply-To: <5lvhlzdu5k.fsf@tequila.systemsz.cs.yale.edu>; from Stefan Monnier on Mon, Oct 05, 1998 at 09:18:15AM -0400 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu -----BEGIN PGP SIGNED MESSAGE----- On Mon, Oct 05, 1998 at 09:18:15AM -0400, Stefan Monnier wrote: [snip] > > In an earlier incarnation of this thread, I seem to remember someone > mentionning some smart behavior of MVS which looks at recent allocation > patterns and kills the faster-growing process. > > Then a program could slowly allocate slow memory chunks till it allocates all the available memory and the kernel kills some inocent process that just started. Loop this untill you have no other process ... eventually the offender will die after slowly putting all the others in the trashcan. - -- Carlos Morgado - l39801@alfa.ist.utl.pt - http://alfa.ist.utl.pt/~c39801 PGP Key fingerprint = 43 BF 53 98 EB 32 F5 17 9E EB 77 1F 57 8C C6 83 Broadcast message from root .... system going down imediatly .... -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNhkKbYewijNBLgpJAQFOKgP+LzcLTiF3Xq8E5NBl8xkWrOn8Er+m5B3g NZsScQU2gNJ8DoqL7Mp26kpSSMD0wgXzNe4rzUIWsSIhotOzaE3kMO1Yo+sAO+BC Hf+O3Tgwq7SMy4a/4XjqROPH2pjPb0hSve8gpfolDdK2RKRXDN8bdGHCrlhoFONX y6BOkcZPoF4/kVa -----END PGP SIGNATURE----- - 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.tux.org/lkml/