From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84402 invoked by alias); 19 Nov 2015 07:53:16 -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 84382 invoked by uid 89); 19 Nov 2015 07:53:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail5.wrs.com Received: from mail5.windriver.com (HELO mail5.wrs.com) (192.103.53.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 19 Nov 2015 07:53:12 +0000 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id tAJ7r8DU010353 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Nov 2015 23:53:08 -0800 Received: from [128.224.162.133] (128.224.162.133) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Nov 2015 23:53:06 -0800 Subject: Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS To: David Smith , , 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> <564CB1DE.5040708@redhat.com> From: yzhu1 Message-ID: <564D7FE4.7050406@windriver.com> Date: Thu, 19 Nov 2015 07:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CB1DE.5040708@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q4/txt/msg00151.txt.bz2 On 11/19/2015 01:14 AM, David Smith wrote: > 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. Hi, David Thanks for your comments. Zhu Yanjun > 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. >