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

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

 



> >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.

Yes, so we agree that #ifdef CONFIG_* is not good.

> 
> 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.

I agree with this suggestion.

Each netlink attribute contains the following fields (also referred to as TLV)

+----+--------+------+
|Type| length | value|
+----+--------+------+

The type is meant to serve the purpose of the header you describe. The
type value can be used by the application to map the data. 
getdelays.c is a sample application posted in the previous patches,
it interprets data based on type.


> 
> 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.
> 

Yes, I think in the long term it would be more useful to use the scheme
of adding subsystem structs. taskstats.txt explains the process of 
extending taskstats. Point #2 is the same as what we have just discussed.
Could you please see if the text needs any changes based on our discussions
so far (taskstats.txt was posted in the delayacct-doc.patch).

> Thanks,
>  - jay
> 
> 

-- 
					<---	Balbir
-
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