Messages in this thread |  | | | Date | Fri, 09 Jun 2006 11:25:58 -0700 | | From | Jay Lan <> | | Subject | Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats |
| |
Shailabh Nagar wrote: > Andrew Morton wrote: > >> On Fri, 09 Jun 2006 16:21:46 +0530 >> Balbir Singh <balbir@in.ibm.com> wrote: >> >> >> >>> Andrew Morton wrote: >>> >>>> On Fri, 09 Jun 2006 03:41:04 -0400 >>>> Shailabh Nagar <nagar@watson.ibm.com> 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? >>>> > Then the tgid stat sending on exit will need to be turned on for > everyone.
I guess that is the limitation of taskstats. One multicast socket for every listeners.
> >>> 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? >> >> > It can choose not to, by not inserting its "fill my fields" function > inside the do..while_each_thread > loop within fill_tgid. So while they would still necessarily receive > the per-tgid taskstats struct on exit > (because some other subsystem needs it), they can atleast save on > filling up their part of the struct > if they don't need it. > >> No other subsystem needs a global knob, does it? >> >> > I didn't understand. > >> 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? >> >> > Yes, thats what will have to be done. If one user wants, all users > will need to get the stats. They can > limit their impact by not processing the parts of the netlink message > that correspond to the per-tgid stats > (since the per-tgid stats are sent as a separate attribute, thats easy > to do). > > This patch covers the use case where someone like CSA is the only user > (delay accounting is turned off) > and wants to reduce the performance impact of the kernel allocating, > sending and userspace discarding > the per-tgid stats. > >> 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? > Yes, its a performance optimization.
Well, for every task exists, two sets of data (of struct taskstats) would be sent from kernel: one is the stats for the pid, the other is the up-to-current stats for the thread (tgid).
Strictly speakly, the second set of data is not per-task stats. For accounting subsystems that do not use thread as aggregation, 50% of the data from the kernel is useless. The option to not sending thread data is very important. Of course we are betting a customer site does not run two different application on the same system.
> >> If so, has it been quantified? >> >> > No :-( > Will try to get some numbers. > Jay/Chris, if you can try to do that too, for the kind of usage that > is typical of CSA, > that would be great.
Probably not until some time next week. But as i point out, 50% of traffic is not useful to CSA.
Thanks, - jay
> > --Shailabh >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |