Re: Kernel text size with pid namespace

[sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org]

Matt Mackall [mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org] wrote:
| On Wed, Sep 19, 2007 at 05:16:44PM -0700, sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
| > Matt,
| > 
| > The pid-namespace patcheset (http://lkml.org/lkml/2007/8/10/118)
| > was added to the -mm tree in 2.6.23-rc3-mm1.
| > 
| > With CONFIG_CC_OPTIMIZE_FOR_SIZE=y this patchset increases the kernel
| > text size by about 5K (closer to 6K when the config token is set to N).
| 
| That's not too bad.

Ok, thanks, I won't worry about for now :-)

Just curious, is there a magic number like 8K or 32K increase in size (of
unconditional code) that one should watch out for ?

| 
| > As a quick test, I uninlined several helper functions and with this
| > the text size increased by about 4K. But since most of these inline
| > functions are used in process creation/termination, we would need to
| > keep them inline, when optimizing for performance.
| 
| You are aware that functions as critical as spinlocks are now
| completely out of line, right? Given that a cache miss is
| significantly more expensive than a function call, fitting more in
| cache by reducing inlining tends to be a substantial win.

I am aware now :-)

| 
| Inline functions still tend to make performance sense when the actual
| function body is more complex than setting up the call frame, of
| course, but in those cases, uninlining will tend to increase code
| size.
| 
| But I'd be very surprised if uninlining things showed up negatively
| even on a microbenchmark like lmbench.
| 
| Also, quick question (I haven't really looked at this code in any detail):
| 
|  static inline pid_t pid_nr(struct pid *pid)
|  {
| 	pid_t nr = 0;
| 	if (pid)
| -	   nr = pid->nr;
| +	      nr = pid->numbers[0].nr;
| +	      return nr;
| +}
| 
| Is calling this with a null struct pid a sensible thing to do or is it
| a bug?

Its not a bug. It just depends on whether the process is exiting or not.

| If the latter, it'd be preferable to just do:
| 
| 	return pid->numbers[0].nr;
| 
| And if the former, could we arrange to avoid using null struct pids at
| all? Perhaps by having a dummy zeropid?

Yes that sounds like a good idea, but requires us to carefully all uses
of the struct pid. Will look into it.

| 
| > Is there a cause for concern with the 5K to 6K increase in text size ?
| > If so, can/should we conditionally inline some functions ? Or move 
| > some pid namespace creation code under CONFIG_TINY or something ?
| > Are there other techniques besides uninling we could apply ?
| > 
| > For reference, I am including below, some numbers for 2.6.23-rc2-mm2
| > kernel for an x86_64 config file.  In the following filenames:
| > 
| > 	"clean" 	no pid ns patches
| > 	"opt-size"	CONFIG_CC_OPTIMIZE_FOR_SIZE=y
| > 	"no-opt"	CONFIG_CC_OPTIMIZE_FOR_SIZE=n
| > 	"uninline"	uninline several new inline functions.
| > 
| > $ size vmlinux*
| > 
| >    text    data     bss     dec     hex filename
| > 
| > 6016101  906266  772424 7694791  7569c7 vmlinux-clean-no-opt-size
| > 6021869  906330  772424 7700623  75808f vmlinux-pidns-no-opt-size
| > 6020805  906330  772424 7699559  757c67 vmlinux-pidns-no-opt-uninline-task-pid
| > 
| > 5299192  906330  772424 6977946  6a799a vmlinux-clean-opt-size
| > 5304588  906394  772424 6983406  6a8eee vmlinux-pidns-opt-size
| > 5303348  906394  772424 6982166  6a8a16 vmlinux-pidns-opt-size-uninline-task-pid
| 
| You might try running scripts/bloat-o-meter against a pair of these.
| 
| -- 
| Mathematics is the supreme nostalgia of our time.