From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118110 invoked by alias); 19 Jul 2018 17:56:03 -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 117982 invoked by uid 89); 19 Jul 2018 17:56:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jul 2018 17:56:01 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A5D697788D; Thu, 19 Jul 2018 17:55:59 +0000 (UTC) Received: from [10.13.129.44] (dhcp129-44.rdu.redhat.com [10.13.129.44]) by smtp.corp.redhat.com (Postfix) with ESMTP id 821A42156700; Thu, 19 Jul 2018 17:55:59 +0000 (UTC) Subject: Re: stap/eBPF language features brainstorm To: Serhei Makarov , systemtap@sourceware.org References: <1531340017.1855006.1437712520.41D1C30F@webmail.messagingengine.com> <01c4f735-68b0-7d0b-11bf-0c89523839ca@redhat.com> <1532021547.3025234.1446386960.12364D48@webmail.messagingengine.com> From: William Cohen Message-ID: <3bd8e141-d5c2-ea38-c4c5-d61fc4e7bc7a@redhat.com> Date: Thu, 19 Jul 2018 17:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1532021547.3025234.1446386960.12364D48@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00030.txt.bz2 On 07/19/2018 01:32 PM, Serhei Makarov wrote: > On Thu, Jul 19, 2018, at 11:27 AM, William Cohen wrote: >> probe timer.ms(5000) { >> /* write out data */ >> /* clear data */ >> delete io_stat >> delete device >> read_bytes = 0 >> write_bytes = 0 >> } >> >> Is there some way to clear out all the previous entries in the bpf map >> from the timer probe? >> >> -Will > > The only ways I can think of to 'clear out' a map from eBPF kernel space are fairly contrived. > > However, in the case of scripts like iotop.stp, there is no reason to run that 5-second timer in kernel-space. I don't see why it would require perf-like precision, so it could be handled by the userspace eBPF interpreter, where such operations are easier to support by iterating through the map elements > > Last time we discussed this, Aaron mentioned some plans to implement support for userspace stapBPF timer probes. I'm not sure what the best option would be for specifying which timer probes should run in userspace and which ones should be handled in the kernel. Perhaps it could be decided automatically depending on whether userspace-only operations such as foreach or map_clear are detected in the probe body. > > All the best, > Serhei > The delete in userspace timer could keep a shadow array of the array and use the delta between the live bpf map array and the shadow array to allow behavior like the current delete operation. However, this doesn't address the problem where the bpf array get full. -Will