Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

[Paul Jackson <pj@sgi.com>]

Shailabh wrote:
> The overhead of creating cpusets just for this
> reason seems excessive when the need is only to
> reduce the number of sockets to monitor

As I reread this thread, some of my ancient interactions with process
accounting come to mind again.

K.I.S.S. - keep it simple, I'm telling myself.

I'm also thinking that since this is a system wide stat tool, it
wants to minimize interactions with other mechanisms.

Hog tying cpusets and process accounting together seems just
plain weird, and risks imposing conflicting demands on the cpuset
configuration of a system.

Please be so kind as to forget I suggested that ;).


How about a simple way to disable collection on specified CPUs.

Collecting this sort of data makes sense for certain managed system
situations, where one chooses to spend some portion of the system
tracking the rest of it.

Collecting it may put an intolerable performance impact on pedal to
the metal maximum performance beasts running on dedicated cpus/nodes.


I propose a per-cpu boolean flag to disable collection.

If this flag is set on the cpu on which a task happens to be when
exiting, then we just drop that data on the floor, silently, with no
accumulation, as quickly as we can, avoiding any system-wide locks.

Then I could run a managed job mix, collecting accounting data, on
some nodes, while running dedicated performance beasts on other nodes,
without the accounting interfering with the performance beasts.

Independently, the cpuset friendly customers could make use of cpusets
to help manage which jobs were on which cpus, so that they collected
their accounting data as desired.  But no need for the accounting
system to be aware of that, past the state of its per-cpu flag.

Such a flag reduces the need for further (over) designing this to
handle the extreme case.  If someone has such an extreme case, they
can turn off collecting on some cpus, to get a handle on the situation.

This could be done as a variant of your idea for multiple
TASKSTATS_LISTEN_GROUP's.  Essentially, for now, we would have two
GROUP's - one that drops the data on the floor, and one that collects
it.  Each cpu is in either one or the other group.  Later on, when the
need arises, we add support for more GROUP's that can actually collect
data.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401