Re: [Lse-tech] Re: [Patch 5/8] taskstats interface

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

 



Hi Balbir,

Balbir Singh wrote:
Are TASKSTATS_GENL_VERSION and TASKSTATS_VERSION the same thing?
If they are meant to serve different purposes, we still need it.



Yes, thats true. But for now from what I can see, one version should
be sufficient.

If we envision a need of it in the future, we'd better put it in
today. It would be nice to have the revision number at beginning of
the struct. Shailabh's instruction says to add new field after existing
fields.


<snip>

I was thinking of a bitmask thing. But instead of keying specific
fields, one bit may be used to key delay accounting, and another bit
for CSA, el at. This way you do not need to have CSA-specifc fields
in the payload and applications know how to correctly interpret the
payload. Taskstats and application do not need to have knowledge of
accounting packages, only need to set the bitmasks correctly.



Yes, but scanning the entire payload for various types is also feasible. It is
a bit slow, but feasible and generally the recommended approach for
dealing with genetlink types. What you are saying is still possible, the
application can ignore types it does not understand.


When we start sending sys stats of each tasks to userland, that is
s lot of data. Note that BSD accounting even uses encode_comp_t()
routine to compress data into a 13-bit fraction with 3-bit exponent
field to shrink its size. Even though you do not need to care
about those zero's in taskstats, they still need to be delievered
through netlink socket.


Yes, thats true. We can leave the decision of compressing, etc to the
specific subsystem. It can encode it and the user level application
can decode the data.

I am sorry that i did not make myself clear. My suggestion of using
the bitmask payload info is to be combined with #ifdef CONFIG_* to
eliminate unnecessary fields from the traffic. I am concerned about
losing data due to application not reading data fast enough.

Well, we can revisit this suggestion when we start losing data
though. ;-)

Regards,
 - jay

-
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