From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16998 invoked by alias); 15 Dec 2011 22:01:02 -0000 Received: (qmail 16977 invoked by uid 22791); 15 Dec 2011 22:01:00 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,LOTS_OF_MONEY,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Dec 2011 22:00:46 +0000 Received: from dlep26.itg.ti.com ([157.170.170.121]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id pBFM0hc2006812; Thu, 15 Dec 2011 16:00:43 -0600 Received: from DNCE72.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id pBFM0ho2024915; Thu, 15 Dec 2011 16:00:43 -0600 (CST) Received: from DNCE03.ent.ti.com ([fe80::19cb:d761:16a6:9b51]) by DNCE72.ent.ti.com ([fe80::8e3:61e5:a5b9:593c%23]) with mapi id 14.01.0323.003; Thu, 15 Dec 2011 23:00:42 +0100 From: "Turgis, Frederic" To: Mark Wielaard CC: "systemtap@sourceware.org" Subject: RE: Making the transport layer more robust - Power Management - follow-up Date: Fri, 16 Dec 2011 15:37:00 -0000 Message-ID: <28BE1A38672C8B4481BB423D0FD1F22E050C468E@DNCE03.ent.ti.com> References: <28BE1A38672C8B4481BB423D0FD1F22E050B4FF9@DNCE03.ent.ti.com> <1323948918.3409.24.camel@springer.wildebeest.org> In-Reply-To: <1323948918.3409.24.camel@springer.wildebeest.org> x-exclaimer-md-config: f9c360f5-3d1e-4c3c-8703-f45bf52eff6b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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/msg00374.txt.bz2 > I noticed these aren't documented anywhere. I propose to document them as= follows: Well written. Maybe we shall avoid converting into ms in documentation beca= use this is very x86 centric, HZ is 128 on ARM (well, at least on OMAP) giv= ing slightly different results ;-) > Would it help you if we made the pool reserved memory buffers also tunabl= e? Currently STP_DEFAULT_BUFFERS is defined staticly in either runtime/tran= sport/debugfs.c (40) or runtime/transport/procfs.c (256) depending which ba= ckend we use for the control channel. It would help but currently, my control buffers are flooded because script = produces warnings/errors that I didn't have in the past (some NULL pointer = backtraced). So my current solution is to correct the script. Control chann= el does not seem to need much bandwidth. > That is probably because not all trace data backends really support poll/= select. The ring_buffer one seems to, but the relay one doesn't. I didn't know. I am using relay (without RELAY kernel flag, module misses s= ome functions) and when I set timeout to 5s, I had the impression that I wa= ke-upsometimes before 5s when I have more traces. But I need to dig in. And= eventually choose ring_buffer. I did my homework on this, increasing trace bandwidth with more prints. Pla= ying with STP_RELAY_TIMER_INTERVAL did not help that much, I still had arou= nd same number of transport failures. Maybe bottleneck was more emptying bu= ffer than checking if there is a buffer to empty. I guess I shall couple mo= re investigation while digging in more into relay/ring_buffer. >Could you file a bug report about the systemtap runtime not noticing new c= ores coming online for bulk mode? Of course... I also did my homework there. If I force both cpus online befo= re test starts, I get the second trace file. I can then force CPU1 offline = then online, everything works fine. So this is really about coming online a= fter start of test, not during test. > Thanks for the feedback. Please let us know how tuning things differently= make your life easier. Currently, thanks to tunables and previous changes, I only need to tune rea= der_thread() timeout to make Power Management team happy. I have coded "str= uct timespec tim =3D {.tv_sec=3D5, .tv_nsec=3D0}". If we can put x * 100000= 0000 in tv_nsec, it could be the tunable, with default=3D200000000 I can also double check that if needed. Regards Fred Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet= . 036 420 040 R.C.S Antibes. Capital de EUR 753.920