From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9974 invoked by alias); 18 Nov 2015 17:14:12 -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 9960 invoked by uid 89); 18 Nov 2015 17:14:11 -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; Wed, 18 Nov 2015 17:14:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ACB5E552FB; Wed, 18 Nov 2015 17:14:09 +0000 (UTC) Received: from t540p.usersys.redhat.com (vpn-54-90.rdu2.redhat.com [10.10.54.90]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAIHE7Px021610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2015 12:14:08 -0500 Subject: Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS To: yzhu1 , sshukla@mvista.com, systemtap@sourceware.org References: <1447747786-29733-1-git-send-email-yanjun.zhu@windriver.com> <1447747786-29733-2-git-send-email-yanjun.zhu@windriver.com> <564B599D.3000506@redhat.com> <564C337B.7060306@windriver.com> From: David Smith Message-ID: <564CB1DE.5040708@redhat.com> Date: Wed, 18 Nov 2015 17:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564C337B.7060306@windriver.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q4/txt/msg00146.txt.bz2 On 11/18/2015 02:14 AM, yzhu1 wrote: > Hi, David > > Thanks for your comments. > > I can not reproduce this problem. And my user can reproduce this problem > ocassionly. > And I requested him to help me to make tests about your changes. But he > refused. > > So I made auto tests in systemtap after this patch is applied. And I can > not find any > regressions about this patch. Most of the time you won't see any difference when using STP_ALLOC_FLAGS in place of STP_ALLOC_SLEEP_FLAGS. You would see a difference if your system is under memory pressure. Let me refresh everyone's knowledge of the difference between STP_ALLOC_FLAGS and STP_ALLOC_SLEEP_FLAGS. When using STP_ALLOC_FLAGS, if memory isn't available, the allocation will fail. When using STP_ALLOC_SLEEP_FLAGS, the kernel will try to wait until memory is available. Obviously, we can only use STP_ALLOC_SLEEP_FLAGS in certain places in the code where sleeping is permitted. If changing STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS makes a difference, this really means that we're using STP_ALLOC_SLEEP_FLAGS in a place where it isn't safe to sleep. It could be that in the normal kernel it is safe to sleep in a spot where we're using STP_ALLOC_SLEEP_FLAGS, but in the realtime kernel it isn't safe to sleep at that same spot. I guess it also makes sense to sleep as little as possible when running systemtap on the realtime kernel. So, I'll withdraw my objection. As long as the switch from STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS only affects the realtime kernel, I'm OK with it. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)