From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030360AbWFISf4 (ORCPT ); Fri, 9 Jun 2006 14:35:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030359AbWFISf4 (ORCPT ); Fri, 9 Jun 2006 14:35:56 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:52622 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1030351AbWFISfz (ORCPT ); Fri, 9 Jun 2006 14:35:55 -0400 Message-ID: <4489BF8F.2060305@engr.sgi.com> Date: Fri, 09 Jun 2006 11:35:59 -0700 From: Jay Lan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060411 X-Accept-Language: en-us, en MIME-Version: 1.0 To: balbir@in.ibm.com CC: Andrew Morton , nagar@watson.ibm.com, jlan@sgi.com, csturtiv@sgi.com, linux-kernel@vger.kernel.org Subject: Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats References: <44892610.6040001@watson.ibm.com> <20060609010057.e454a14f.akpm@osdl.org> <448952C2.1060708@in.ibm.com> <20060609042129.ae97018c.akpm@osdl.org> <44899562.6010609@in.ibm.com> In-Reply-To: <44899562.6010609@in.ibm.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Balbir Singh wrote: > Andrew Morton wrote: >> On Fri, 09 Jun 2006 16:21:46 +0530 >> Balbir Singh wrote: >> >> >>> Andrew Morton wrote: >>> >>>> On Fri, 09 Jun 2006 03:41:04 -0400 >>>> Shailabh Nagar wrote: >>>> >>>> >>>> >>>>> Hence, this patch introduces a configuration parameter >>>>> /sys/kernel/taskstats_tgid_exit >>>>> through which a privileged user can turn on/off sending of >>>>> per-tgid stats on >>>>> task exit. >>>> >>>> >>>> That seems a bit clumsy. What happens if one consumer wants the >>>> per-tgid >>>> stats and another does not? >>> >>> For all subsystems that re-use the taskstats structure from the exit >>> path, >>> we have the issue that you mentioned. Thats because several >>> statistics co-exist >>> in the same structure. These subsystems can keep their tgid-stats >>> empty by not >>> filling up anything in fill_tgid() or using this patch to >>> selectively enable/disable >>> tgid stats. >>> >>> For other subsystems, they could pass tgidstats as NULL to >>> taskstats_exit_send(). >>> >> >> >> I don't understand. If a subsystem exists then it fills in its slots in >> the taskstats structure, doesn't it? >> >> No other subsystem needs a global knob, does it? >> >> You see the problem - if one userspace package wants the tgid-stats and >> another concurrently-running one does now, what do we do? Just leave it >> enabled and run a bit slower? > > Another option is to get the package to define their own taskstats > genetlink attribute and fill it up in taskstats_exit_send(). This > would be similar to > TASKSTATS_TYPE_AGGR_PID/TGID. > > They can make this attribute independent of the taskstats structure > and fill > it based on their policy (per-pid or per-tgid). But the current interface > users like CSA want to build on top of the taskstats structure. That was my question to you from the beginning: do you propose a common interface based on taskstats or genetlink? If CSA defines its own taskstats genetlink attirbute, does it listen to the same socket as delayacct? If yes, then the socket will be jammed with duplicate information before long. Is it an option to make per-tgid data a unicast? Ie, your daemon periodically polling the per-tgid stats? Thanks, - jay > >> >> If so, how much slower? Your changelog says some potential users don't >> need the tgid-stats, but so what? I assume this patch is a performance >> thing? If so, has it been quantified? >> > >