From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 9 Nov 2009 09:28:09 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <<13426df10911081656q75a7b5aawd01dc9df71beca08@mail.gmail.com>> References: <<13426df10911081656q75a7b5aawd01dc9df71beca08@mail.gmail.com>> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 981b9c7c-ead5-11e9-9d60-3106f5b1d025 On Sun Nov 8 19:58:08 EST 2009, rminnich@gmail.com wrote: > On Sun, Nov 8, 2009 at 4:07 PM, wrote: > > > I'd be happy to see a BPF-style filter in the kernel for filtering events > > before chucking them up to userland, > > Point taken. I could pretty easily put a simple filter like that in > devtrace. It's just a question of what's needed. bpf-style filters address a situation where jitter is not important, one potentally large packet is returned per system call and there may be many filters sitting on the same interfaces. with devtrace, the situation is the opposite. jitter is important (to eliminate), 541 small fixed-sized events can be returned per system call and there is one trace device per system. tracepoints can already be inserted on a single function entry or exit and be filtered by pid. the common problem between bpf and devtrace is buffer space. i haven't run into this problem yet, but lowering KZERO by 256mb would be enough for an additiona 7.4 million (32-bit) buffered tracepoints. - erik