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

[Jay Lan]

Balbir Singh wrote:
>>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.
>>
>>    
>
>Yes, true. It does not hurt to have a version number for taskstats.
>I will add it in.
>
><snip>
> 
>  
>>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. ;-)
>>    
>
>Like Shailabh said #ifdef CONFIG_* adds complexity for userspace parsing
>of the structure, but if it helps avoid sending unnecessary data we
>can consider using that approach. 
>
>Would something like the structure below be useful?
>
>struct csastats {
>#if defined(CONFIG_CSA) || defined(CONFIG_CSA_MODULE)
>       char    acctent[sizeof(struct acctcsa) +
>                       sizeof(struct acctmem) +
>                       sizeof(struct acctio)];
>       int     filled;
>#endif
>};
>
>The filled member can be a bool or an int to indicate that the structure
>contains meaningful data and the CONFIG_* is used to control the
>inclusion of meaningful fields. Instead of using a bitmap we use
>the filled member.
>
>Is this what you had in mind?
>  
No exactly. The payload information must be always available for
application.

On a second thought, the idea of one big taskstats struct with many
#ifconfig is not really a good idea. My goal is to cut down unnecessary
data being transfered throught the socket.

Here is my Take 2. We can have a  taskstats header containing taskstats
version and other general fields useful to more than one taskstats
application including a payload information. Then, we define
accounting subsystem specific structs for delayacct, csa, etc.
The kernel/{delayacct.c,csa.c,etc.c} set the payload information and
fill the buffer with desired subsystem structs. The header thus contain
enough information to tell  applications how to map the data following
the header.

Would IBM propose more accounting subsystems besides delayacct?
If we only see delayacct and csa on the horizon, this scheme is really
not necessary since delayacct does not have as much data (as csa :))
and csa can use part of the delayacct data. You gain more than
csa can benefit from this. ;-) I guess i just speak from design point
of view. :)

But, if one day somebody who does not need a paycheck decides
to convert BSD accounting to use taskstats interface, this can
be helpful.

Thanks,
 - jay



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