From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5846 invoked by alias); 6 Nov 2006 22:15:56 -0000 Received: (qmail 5839 invoked by uid 22791); 6 Nov 2006 22:15:56 -0000 X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Nov 2006 22:15:48 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 06 Nov 2006 14:15:47 -0800 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2006 14:15:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="158955623:sNHT21462973" Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Nov 2006 14:15:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: offline elfutils processing committed Date: Mon, 06 Nov 2006 22:41:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: offline elfutils processing committed Thread-Index: AccB6SWwrwqSx7FiTbeGRS9hQIX3OAABty6A From: "Stone, Joshua I" To: "Martin Hunt" , "Frank Ch. Eigler" Cc: X-OriginalArrivalTime: 06 Nov 2006 22:15:42.0324 (UTC) FILETIME=[191A2B40:01C701F1] X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00355.txt.bz2 On Monday, November 06, 2006 1:18 PM, Martin Hunt wrote: > The point is damage control. Systemtap allocates too much memory and > oom killer gets active, the first thing it will kill is staprun and > that should unload the module (but this seems broken at the moment).=20 > So we haven't really hurt the system. The goal is fine, but I don't think this accomplishes it. My understanding is that __alloc_pages will keep calling OOM until it is able to satisfy the request -- thus the module is blocked waiting for memory. The process might end up something like: stap module: allocate lots of memory __alloc_pages: Not enough memory -> OOM kill something (staprun) __alloc_pages: Still not enough memory -> OOM kill other stuff __alloc_pages: Yay, now we have enough memory! stap module: got some memory stap module: Oops, staprun is gone, better exit... Ouch... Josh