Re: [PATCH 2.6.9-rc2 2/2] enhanced MM accounting data collection

Paul Jackson <[email protected]> Tue, 28 Sep 2004 02:33:50 -0700
Newsgroups gmane.linux.comprehensive-system-accounting,gmane.linux.kernel,gmane.linux.lse
Organization SGI
Message-ID <[email protected]>
nits:

1) I'm not sure the "no-op if CONFIG_CSA not set" comments
   are worthwhile - it does not seem to be a common practice
   to mark macros that collapse under certain CONFIG's with
   such comments, and some code, such as in fork.c, would
   become quite a bit less readable if such comments were
   widely used.

2) Three of the added csa_update_integrals() lines have
   leading spaces, instead of a tab char, such as in:

===================================================================
--- linux.orig/fs/exec.c	2004-09-27 11:57:40.201435722 -0700
+++ linux/fs/exec.c	2004-09-27 14:05:41.266160725 -0700
@@ -1163,6 +1164,9 @@
 
 		/* execve success */
 		security_bprm_free(&bprm);
+		/* no-op if CONFIG_CSA not set */
+                csa_update_integrals();		<=========
+                update_mem_hiwater();			<=========
 		return retval;
 	}
 
3) Is it always the case that csa_update_integrals() and
   update_mem_hiwater() are used together?  If so, perhaps
   they could be collapsed into one?  Even the current->mm
   test inside them could be made one test, perhaps?

4) What kind of kernel text size expansion does this cause?
   There seem to be about a dozen of these calls.  What are
   the pros and cons of inlining csa_update_integrals() and
   update_mem_hiwater()?  Are these on hot enough kernel code
   paths that we should benchmark with and without these hooks
   enabled, both inline and out-of-line?

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <[email protected]> 1.650.933.1373