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

[Jay L. <jl...@en...>]

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