From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25933 invoked by alias); 16 Jun 2009 23:13:10 -0000 Received: (qmail 25922 invoked by uid 22791); 16 Jun 2009 23:13:09 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_75,SARE_MSGID_LONG40 X-Spam-Check-By: sourceware.org Received: from mail-fx0-f210.google.com (HELO mail-fx0-f210.google.com) (209.85.220.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Jun 2009 23:13:03 +0000 Received: by fxm6 with SMTP id 6so5367716fxm.24 for ; Tue, 16 Jun 2009 16:13:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.110.3 with SMTP id l3mr5870443fap.48.1245193980661; Tue, 16 Jun 2009 16:13:00 -0700 (PDT) In-Reply-To: <4A369CCD.60004@redhat.com> References: <1244936781.212635.16785@debian> <4A369CCD.60004@redhat.com> Date: Tue, 16 Jun 2009 23:13:00 -0000 Message-ID: <40e92d5b0906161613m399497ecg89290c4687e01227@mail.gmail.com> Subject: Re: [PATCH] Fix target_set tapset. From: =?ISO-8859-2?Q?Przemys=B3aw_Pawe=B3czyk?= To: Josh Stone Cc: systemtap@sourceware.org Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 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: 2009-q2/txt/msg00916.txt.bz2 On Mon, Jun 15, 2009 at 21:11, Josh Stone wrote: > On 06/13/2009 04:10 PM, Przemyslaw Pawelczyk wrote: >> Add pid removal on exit syscall. Use dwarfless syscall probe aliases. >> Correct formatting. >> --- > [...] >> -probe syscall.fork.return >> +probe nd_syscall.fork.return > > What do you think about preferring process.begin for utrace-enabled > kernels? That should be lower overhead than a kprobe trap. This sounds good, however it leads to different path-execution on various kernels and that is not good. IMHO better would be creating another target_set-like tapset, but utrace-based only. >> +probe nd_syscall.exit >> +{ >> + delete _target_set[pid()] >> } > > The problem is that this makes target_set_report() useless after the > processes have exited (e.g. in an end probe). I think we should just > trust that the target process won't beget more than MAXMAPENTRIES > children. At the default 2048, that will probably be fine most of the ti= me. It should be useless after the precesses have exited, because then target_set contains only target() or is even empty (depends on what we mean by the processes), right? If it is really target_set, then as name suggests it should be valid all the time. Pid collisions are rare, but not impossible. > If you really want this, perhaps we could instead add the pid to a death > array, and then have a function to clear those out. The clear could > either be explicitly called, or perhaps it would be an implicit call at > the end of target_set_report. Then the calling script can do periodic > clear/reports if it knows there will be more than MAXMAPENTRIES children. Death pid array is other solution, but clearing routine definitely shouldn't be located in target_set_report. Moreover target_set_report shouldn't even print death pids, but new function could do this (target_set_already_dead_report?). And if we're after this option, then I can agree only if there is a separate clear function without implicit calls in reporting functions with exception for functions clearly pointing this out (target_set_already_dead_report_and_clear?). > Josh Regards. --=20 Przemys=B3aw Pawe=B3czyk