From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12521 invoked by alias); 25 Oct 2011 12:07:17 -0000 Received: (qmail 12507 invoked by uid 22791); 25 Oct 2011 12:07:14 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Oct 2011 12:06:55 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9PC6sJm019044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Oct 2011 08:06:54 -0400 Received: from fche.csb (vpn-10-200.rdu.redhat.com [10.11.10.200]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9PC6s2M010596; Tue, 25 Oct 2011 08:06:54 -0400 Received: by fche.csb (Postfix, from userid 2569) id 879D858131; Tue, 25 Oct 2011 08:06:53 -0400 (EDT) To: Josh Stone Cc: Mark Wielaard , systemtap@sourceware.org, dsmith@redhat.com Subject: Re: Fixed PR13146 by not allowing memory allocations to sleep References: <20110901143940.13672.qmail@sourceware.org> <1317135124.3361.22.camel@springer.wildebeest.org> <4E82481E.8060502@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Tue, 25 Oct 2011 12:07:00 -0000 In-Reply-To: <4E82481E.8060502@redhat.com> (Josh Stone's message of "Tue, 27 Sep 2011 15:03:10 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q4/txt/msg00107.txt.bz2 jistone wrote: > [...] > I agree, those contexts which can sleep, should. Not only does this > make it more likely we'll get the memory we want, but also makes us > better citizens with the rest of the kernel. Unfortunately, that's not quite sound policy either. The memory allocation aggressiveness pendulum has swung too far with the new code, and now large data structures are allocated with plain GFP_KERNEL. On small-memory machines, this is found to OOM the system, rather than let the stap module give up early. An intermediate approach is needed; maybe __GFP_REPEAT & !__GFP_NOWAIT. - FChE