lkml.org 
[lkml]   [2004]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Patch 17/23] mask v2 = [6/7] nodemask_t_ia64_changes
Date
On Tuesday 06 April 2004 14:37, Paul Jackson wrote:
> Matthew,
>
> A couple of these nodemask changes are increasing kernel text size quite
> a bit on big numa configurations.
>
> I've got one test case I ran where the text size of vmlinux increased
> from 8789097 to 8810513 bytes (2.6.5 kernel for ia64 SN2 NR_CPUS=512
> sn2_defconfig, gcc 3.2.3).
>
> From a cursory comparson of 'nm --print-size --size-sort' output,
> I think the increased space is caused by the numerous numnodes
> changes, such as:
>
> - pxm_to_nid_map[i] = numnodes;
> - nid_to_pxm_map[numnodes++] = i;
> + pxm_to_nid_map[i] = num_online_nodes();
> + nid_to_pxm_map[num_online_nodes()] = i;
> + node_set_online(num_online_nodes());
>
> And by the for loop replacements:
>
> - for (nid = 0, i = 0; i < numnodes; i++) {
> + nid = 0;
> + for_each_online_node(i) {
>
> In particular, the machine code generated by the following silly little
> routine:
>
> int foo() { int i = 0, n; for_each_online_node(n) i++; return i; }
>
> is ... hold onto your hat ...
>
> a000000100116f40 <foo>:
> a000000100116f40: 00 10 20 02 29 26 [MII] addl r2=-2091896,r1
> a000000100116f46: 80 00 00 00 42 20 mov r8=r0
> a000000100116f4c: 02 00 08 90 mov r17=256

<~700 bytes of code snipped away>

> a000000100117256: 00 00 00 02 00 80 nop.i 0x0
> a00000010011725c: 08 00 84 00 br.ret.sptk.many b0;;

Deinlining will help, but why such a simple thing require 700 bytes of code in
the first place? (assuming it's not a gcc drain bamage and non-inlined
for_each_online_node(n) will be of comparable size)
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.159 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site