From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121390 invoked by alias); 27 Oct 2015 13:52:54 -0000 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 Received: (qmail 121381 invoked by uid 89); 27 Oct 2015 13:52:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 27 Oct 2015 13:52:53 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 0A67EC0B5923; Tue, 27 Oct 2015 13:52:52 +0000 (UTC) Received: from fche.csb (vpn-54-185.rdu2.redhat.com [10.10.54.185]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9RDqpli025836; Tue, 27 Oct 2015 09:52:51 -0400 Received: by fche.csb (Postfix, from userid 2569) id 6E8D05868F; Tue, 27 Oct 2015 09:52:51 -0400 (EDT) To: David Smith Cc: yzhu1 , systemtap@sourceware.org Subject: Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS References: <1445499965-23777-1-git-send-email-yanjun.zhu@windriver.com> <56290FFC.3030407@redhat.com> <562D9BAA.7040704@windriver.com> <562E9AE0.6030501@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Tue, 27 Oct 2015 13:52:00 -0000 In-Reply-To: <562E9AE0.6030501@redhat.com> (David Smith's message of "Mon, 26 Oct 2015 16:28:00 -0500") 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 X-SW-Source: 2015-q4/txt/msg00070.txt.bz2 dsmith wrote: > [...] > Here's the big question - on the realtime kernel, is it ever safe to sleep? > If the answer to the previous question is "no", then your change > [switching to STP_ALLOC_FLAGS] is correct. [...] But even then, not in general. If we use atomic memory allocation flags only, we may suffer unnecessary alloc failures on normal kernels. If we do this switch, perhaps it needs to be done rt-conditionally. It might be as simple as to "#define STP_ALLOC_SLEEP_FLAGS ..." differently on rt (CONFIG_*...). - FChE