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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Morton wrote:

On Fri, 30 Jun 2006 22:20:23 -0400
Shailabh Nagar <[email protected]> wrote:

If we're going to abuse nl_pid then how about we design things so that
nl_pid is treated as two 16-bit words - one word is the start CPU and the
other word is the end cpu?

Or, if a 65536-CPU limit is too scary, make the bottom 8 bits of nl_pid be
the number of CPUS (ie: TASKSTATS_CPUS_PER_SET) and the top 24 bits is the
starting CPU.
<avoids mentioning nl_pad>

It'd be better to use a cpumask, of course..


All these options mean each listener gets to pick a "custom" range of cpus to listen on, rather than choose one of pre-defined ranges (even if the pre-defined ranges can change by a configurable TASKSTATS_CPUS_PER_SET). Which means the kernel side has to figure out which of the listeners cpu range includes the currently exiting task's cpu. To do this, we'll need a callback from the binding of the netlink socket (so taskstats can maintain
the cpu -> nl_pid mappings at any exit).
The current genetlink interface doesn't have that kind of flexibility (though it can be added
I'm sure).

Seems a bit involved if the primary aim is to restrict the number of cpus that one listener
wants to listen, rather than be able to pick which ones.

A configurable range won't suffice ?


Set aside the implementation details and ask "what is a good design"?

A kernel-wide constant, whether determined at build-time or by a /proc poke
isn't a nice design.

Can we permit userspace to send in a netlink message describing a cpumask? That's back-compatible.
Yes, that should be doable. And passing in a cpumask is much better since we no longer
have to maintain mappings.

So the strawman is:
Listener bind()s to genetlink using its real pid.
Sends a separate "registration" message with cpumask to listen to. Kernel stores (real) pid and cpumask. During task exit, kernel goes through each registered listener (small list) and decides which one needs to get this exit data and calls a genetlink_unicast to each one that does need it.

If number of listeners is small, the lookups should be swift enough. If it grows large, we can consider a fancier lookup (but there I go again, delving into implementation too early :-)


Sounds good to me !

--Shailabh







-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux