[PATCH 0/2] taskstats: uglify^Woptimize reply assembling

[PATCH 0/2] taskstats: uglify^Woptimize reply assembling

[Oleg Nesterov]

The last series.

Balbir, Shailabh, could you suggest me some user-space tests?

Thomas, we are doing genlmsg_cancel() before nlmsg_free(), this is
not necessary. Unless you have evil plans to complicate genetlink
we can remove a little bit of code, what do you think?

Oleg.

Re: [PATCH 0/2] taskstats: uglify^Woptimize reply assembling

[Shailabh Nagar]

Oleg Nesterov wrote:
> The last series.
> 
Thanks again for the refactoring/review and optimizations to the code
base. Some of the earlier patches I'm still processing (to be sure the
timings etc. of signal clearing vs. task exit are right) but these later
ones are pretty straightforward and look good. Testing needed of course.

> Balbir, Shailabh, could you suggest me some user-space tests?

For stress testing, what we've used is to run

- one listener continuously getting exit stats (prototype listener
code in Documentation/accounting/getdelays.c)
- a multithreaded app where each thread does some disk I/O and some
cpu processing (incrementing a count etc.), threads get created and
destroyed in a continuous loop
- periodically query the multithreaded app above (print out its tgid first)
using another instance of Documentation/accounting/getdelays.c to see
if the delay data is getting incremented as expected by what the threads do.
- cerebrus and/or kernel compiles running in background just to create
a load

You can drop the cerebrus etc. if the load gets too much.

Running the above past a few hours has caught the kind of bugs seen so far.

> 
> Thomas, we are doing genlmsg_cancel() before nlmsg_free(), this is
> not necessary. Unless you have evil plans to complicate genetlink
> we can remove a little bit of code, what do you think?
> 
> Oleg.
> 

Re: [PATCH 0/2] taskstats: uglify^Woptimize reply assembling

[Balbir Singh]

Oleg Nesterov wrote:
> The last series.
> 
> Balbir, Shailabh, could you suggest me some user-space tests?

Hi, Oleg,

We generally use getdelays (see Documentation/accounting/getdelays.c)
for getting data of all running processes running on the system
frequently along with a stress suite like cerebrus (ctcs) running
on the side.


-- 

	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs

Re: [PATCH 0/2] taskstats: uglify^Woptimize reply assembling

[Thomas Graf]

* Oleg Nesterov <oleg@tv-sign.ru> 2006-11-01 21:25
> Thomas, we are doing genlmsg_cancel() before nlmsg_free(), this is
> not necessary. Unless you have evil plans to complicate genetlink
> we can remove a little bit of code, what do you think?

genlmsg_cancel() is only required in error paths for dumping
procedures.

[PATCH] fix Documentation/accounting/getdelays.c buf size

[Oleg Nesterov]

getdelays reports a "fatal reply error, errno 258". We don't have enough room
for multi-threaded exit (PID + TGID).

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

--- STATS/Documentation/accounting/getdelays.c~	2006-10-22 18:23:57.000000000 +0400
+++ STATS/Documentation/accounting/getdelays.c	2006-11-02 20:25:22.000000000 +0300
@@ -49,7 +49,7 @@ __u64 stime, utime;
 	}
 
 /* Maximum size of response requested or message sent */
-#define MAX_MSG_SIZE	256
+#define MAX_MSG_SIZE	1024
 /* Maximum number of cpus expected to be specified in a cpumask */
 #define MAX_CPUS	32
 /* Maximum length of pathname to log file */