From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11485 invoked by alias); 5 Sep 2011 11:27:15 -0000 Received: (qmail 11477 invoked by uid 22791); 5 Sep 2011 11:27:14 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_YF 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; Mon, 05 Sep 2011 11:26:53 +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 p85BQrA9028699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2011 07:26:53 -0400 Received: from springer.wildebeest.org (ovpn-113-38.phx2.redhat.com [10.3.113.38]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p85BQp6V008426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Sep 2011 07:26:52 -0400 Received: by springer.wildebeest.org (Postfix, from userid 500) id 922D0409B9; Mon, 5 Sep 2011 13:26:50 +0200 (CEST) Subject: RE: Making the transport layer more robust From: Mark Wielaard To: "Turgis, Frederic" Cc: "systemtap@sourceware.org" In-Reply-To: <13872098A06B02418CF379A158C0F1460162DC0A08@dnce02.ent.ti.com> References: <1311065908.9144.27.camel@springer.wildebeest.org> <20110812174324.GA1394@hermans.wildebeest.org> <4E4965B3.6080700@redhat.com> <1313500965.3393.5.camel@springer.wildebeest.org> <13872098A06B02418CF379A158C0F1460162DC0A08@dnce02.ent.ti.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 05 Sep 2011 11:27:00 -0000 Message-ID: <1315222009.3431.22.camel@springer.wildebeest.org> Mime-Version: 1.0 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-q3/txt/msg00266.txt.bz2 Hi Turgis, On Thu, 2011-08-25 at 14:12 +0200, Turgis, Frederic wrote: > =3D> long polling delay works OK, kernel periodic check for IO seems > redundant with userspace but kernel polling for exit is needed The kernel side "polling" is not just for exit, it is for any cmd message that is generated from a possible "unsafe" context. We might want to investigate whether we can be a little smarter about this (maybe use inatomic() as a check whether we may announce immediately or need the timer, and/or make the timer smarter so it fires less frequently when we don't expect any messages?). > - after changes: > * userspace: we use "pselect" if supported. Great ! > * kernel space: > + polling for exit is still needed > + polling for IO: > * for cmd messages that don't announce themselves -> now > mandatory otherwise pselect() would not return > * for other cmd messages, it still does not look needed but > there is no added value in differentiating them from above messages as > we must do polling >=20 > =3D> we will experiment with this version playing only with the delay > between 2 pollings (STP_CTL_TIMER_INTERVAL) I am very interested in any results you get from the new code. Note that there is another timer firing periodically for "normal" transport messages (none-command/warn/err/exit/system). This is controlled by STP_RELAY_TIMER_INTERVAL. This is needed because relayfs can only notify user space on "buffer overflow". So when running stap in "line mode" (aka non-bulk-mode, not using stap -b), the kernel-side needs to periodically poll to see if any new messages should be immediately given to user space. Running in bulk-mode (-b) will completely get rid of this timer, but I don't yet know how to make it less noticeable for line-mode, when you want to get notified about probe messages immediately. Please let us know about any experiments you run that might help us better tune these timers. Thanks, Mark