RE: Multiple virtual address mapping for the same code on IA-64 linux kernel.

RE: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[Luck, Tony]

>I have been investigating a problem in which there has been a dramatic
> core size (complete program size) of a program running on a IA-64
>machine running kernel version 2.4.21-4.0.1 (A redhat advanced server
>distribution) compared to other 64-bit architectures like amd64 and
>EM64T. There has been an increase of around 20% of the size.

Itanium instruction set is not as compact as some other architectures,
so the same program will typically require more bytes of code.

-Tony

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[vamsi krishna]

Hello All,

Really thankful for your inputs!

> Itanium instruction set is not as compact as some other architectures,
> so the same program will typically require more bytes of code.

I stopped the program on both amd64 machine and ia64 machine and
grepped the values from /proc/<>/status and found the following.

<----Linux IPF----------->
VmSize:   126304 kB
VmLck:         0 kB
VmRSS:      6352 kB
VmData:    19696 kB
VmStk:        16 kB
VmExe:     97760 kB
VmLib:      3152 kB
<------------------------>

<------AMD64------------->
VmSize:   100432 kB
VmLck:         0 kB
VmRSS:      2828 kB
VmData:    24428 kB
VmStk:       264 kB
VmExe:     62848 kB
VmLib:      3048 kB
<----------------------->

Seems like most of core size(VmSize) on ipf (126MB) is coming from the
code size(VmExe) i.e 97MB. While the code size is just 62MB on amd64.

Looks like IA-64 wastes a lot of VM due to big instruction sizes, so
big instruction sizes will improve performance ? compared small
instruction sizes? , but fetching big instructions surely takes time
compared to small, this may be the reason why amd64 is the fasttest
64-bit process ?

Thanks a lot!
Vamsi

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[Christoph Lameter]

On Wed, 17 Aug 2005, vamsi krishna wrote:

> Seems like most of core size(VmSize) on ipf (126MB) is coming from the
> code size(VmExe) i.e 97MB. While the code size is just 62MB on amd64.
> 
> Looks like IA-64 wastes a lot of VM due to big instruction sizes, so
> big instruction sizes will improve performance ? compared small
> instruction sizes? , but fetching big instructions surely takes time
> compared to small, this may be the reason why amd64 is the fasttest
> 64-bit process ?

IA64 arranges instructions in word size bundles in order to optimize 
instruction fetch. Current GCC versions cannot properly optimize for 
the parallelism capabilities of the Itanium processor and thus many 
slots are filled with nop. Hopefully that will become better in gcc 4.X.

Itanium processors are the fastest 64bit processors at any given clock 
frequency. The earlier generations of processors do not even have the 
instruction set that would enable the processor to do more parallel 
processing. =-)

Please do not make such inflammatory statements on the 
ia64 list.

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[Alan Cox]

On Mer, 2005-08-17 at 12:52 -0700, Christoph Lameter wrote:
> > compared to small, this may be the reason why amd64 is the fasttest
> > 64-bit process ?

> Itanium processors are the fastest 64bit processors at any given clock 
> frequency.

Perhaps, and the two statements don't contradict. All he was doing was
asking a very sensible architecture question to understand why the IA64
binary was so big.

> Please do not make such inflammatory statements on the 
> ia64 list.

Since when has asking sensible questions been "inflammatory statements".
If thats how you treat the people actually porting to IA64 then its out
of order, at least for linux-kernel, which is where you cross posted.

Alan

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[Anton Blanchard]

 
> Itanium processors are the fastest 64bit processors at any given clock 
> frequency. The earlier generations of processors do not even have the 
> instruction set that would enable the processor to do more parallel 
> processing. =-)
> 
> Please do not make such inflammatory statements on the 
> ia64 list.

Calling itanium the "fastest 64bit processor at any given clock frequency"
on lkml is likewise inflammatory :)

Anton

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[David S. Miller]

From: Anton Blanchard <anton@samba.org>
Date: Fri, 19 Aug 2005 04:29:55 +1000

> Calling itanium the "fastest 64bit processor at any given clock frequency"
> on lkml is likewise inflammatory :)

I totally agree.

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[George Anzinger]

David S. Miller wrote:
> From: Anton Blanchard <anton@samba.org>
> Date: Fri, 19 Aug 2005 04:29:55 +1000
> 
> 
>>Calling itanium the "fastest 64bit processor at any given clock frequency"
>>on lkml is likewise inflammatory :)
> 
> 
> I totally agree.

Since the itanium off loads a lot of its instruction steam decisions on 
to the compiler(s), where other processors just do it, one might argue 
that you can not even characterize the itanium without bundling in the 
compilers...

Not to say that is wrong but just to make it clear that saying the 
itanium speed is <X> is like saying that a cummings diesel is fast with 
out saying what sort of car/truck it is mounted in.

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[Ingo Oeser]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Hi,

On Friday 19 August 2005 00:18, George Anzinger wrote:
> Not to say that is wrong but just to make it clear that saying the 
> itanium speed is <X> is like saying that a cummings diesel is fast with 
> out saying what sort of car/truck it is mounted in.

Yes, esp. since we all known that the fastest diesel is actually
Vin Diesel :-)


Have Fun!

Ingo Oeser


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Multiple virtual address mapping for the same code on IA-64 linux kernel.

[vamsi krishna]

Hello All,

Sorry to interrupt you.

I have been investigating a problem in which there has been a dramatic
 core size (complete program size) of a program running on a IA-64
machine running kernel version 2.4.21-4.0.1 (A redhat advanced server
distribution) compared to other 64-bit architectures like amd64 and
EM64T. There has been an increase of around 20% of the size.

I verified the virtual address mappings in /proc/<>/maps file and
found that several .so files (other segments of same size) are getting
mapped multiple times as follows.
<------------------------------------------------------------------------------------------------>
200000000005c000-200000000007c000 r-xp 0000000000000000 08:07 6521003 
  /usr/X11R6/lib/libXext.so.6.4
200000000007c000-2000000000090000 rw-p 0000000000010000 08:07 6521003 
  /usr/X11R6/lib/libXext.so.6.4
2000000000090000-2000000000268000 r-xp 0000000000000000 08:07 6520995 
  /usr/X11R6/lib/libX11.so.6.2
2000000000268000-2000000000270000 ---p 00000000001d8000 08:07 6520995 
  /usr/X11R6/lib/libX11.so.6.2
2000000000270000-2000000000284000 rw-p 00000000001d0000 08:07 6520995 
  /usr/X11R6/lib/libX11.so.6.2
2000000000284000-200000000028c000 r-xp 0000000000000000 08:07 6094863 
  /lib/libdl-2.2.4.so
200000000028c000-2000000000294000 ---p 0000000000008000 08:07 6094863 
  /lib/libdl-2.2.4.so
2000000000294000-200000000029c000 rw-p 0000000000000000 08:07 6094863 
  /lib/libdl-2.2.4.so
200000000029c000-20000000002b8000 r-xp 0000000000000000 08:07 6094883 
  /lib/libpthread-0.9.so
20000000002b8000-20000000002bc000 ---p 000000000001c000 08:07 6094883 
  /lib/libpthread-0.9.so
20000000002bc000-20000000002d4000 rw-p 0000000000010000 08:07 6094883 
  /lib/libpthread-0.9.so
20000000002d4000-2000000000358000 r-xp 0000000000000000 08:07 376886  
  /usr/lib/libncurses.so.5.2
2000000000358000-2000000000364000 ---p 0000000000084000 08:07 376886  
  /usr/lib/libncurses.so.5.2
2000000000364000-2000000000374000 rw-p 0000000000080000 08:07 376886  
  /usr/lib/libncurses.so.5.2
2000000000374000-2000000000378000 rw-p 0000000000000000 00:00 0
2000000000378000-2000000000400000 r-xp 0000000000000000 08:07 6094865 
  /lib/libm-2.2.4.so
2000000000400000-2000000000408000 ---p 0000000000088000 08:07 6094865 
  /lib/libm-2.2.4.so
2000000000408000-2000000000414000 rw-p 0000000000080000 08:07 6094865 
  /lib/libm-2.2.4.so
2000000000414000-200000000065c000 r-xp 0000000000000000 08:07 6094859 
  /lib/libc-2.2.4.so
200000000065c000-2000000000664000 ---p 0000000000248000 08:07 6094859 
  /lib/libc-2.2.4.so
2000000000664000-2000000000678000 rw-p 0000000000240000 08:07 6094859 
  /lib/libc-2.2.4.so
<------------------------------------------------------------------------------------------->

example /lib/libc-2.2.4.so size 6094859    got mapped 3 times with
permissions 'r-xp' , '---p' and 'rw-p' from the bottom.

I found the similar mappings for all the programs running on a IA-64
machine. Is this some special kernel kind of feature on IA-64 ??

Your kind inputs on this problem are greatly appreciated.

Looking forward to hear from you.

Thanks in advance,
Vamsi kundeti

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[Andreas Schwab]

vamsi krishna <vamsi.krishnak@gmail.com> writes:

> example /lib/libc-2.2.4.so size 6094859    got mapped 3 times with
> permissions 'r-xp' , '---p' and 'rw-p' from the bottom.

Note the file offset.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

[linux-os (Dick Johnson)]

On Tue, 16 Aug 2005, vamsi krishna wrote:

> Hello All,
>
> Sorry to interrupt you.
>
> I have been investigating a problem in which there has been a dramatic
> core size (complete program size) of a program running on a IA-64
> machine running kernel version 2.4.21-4.0.1 (A redhat advanced server
> distribution) compared to other 64-bit architectures like amd64 and
> EM64T. There has been an increase of around 20% of the size.
>

The IA-64 instruction-set is bigger than, for instance, AMD-64.
This could account for some code-size increase. It's also possible
that the 'C' compiler was doing more in-lining as well when the
libraries were built.

> I verified the virtual address mappings in /proc/<>/maps file and
> found that several .so files (other segments of same size) are getting
> mapped multiple times as follows.
> <------------------------------------------------------------------------------------------------>
> 200000000005c000-200000000007c000 r-xp 0000000000000000 08:07 6521003
>  /usr/X11R6/lib/libXext.so.6.4
> 200000000007c000-2000000000090000 rw-p 0000000000010000 08:07 6521003
>  /usr/X11R6/lib/libXext.so.6.4
> 2000000000090000-2000000000268000 r-xp 0000000000000000 08:07 6520995
>  /usr/X11R6/lib/libX11.so.6.2
> 2000000000268000-2000000000270000 ---p 00000000001d8000 08:07 6520995
>  /usr/X11R6/lib/libX11.so.6.2
> 2000000000270000-2000000000284000 rw-p 00000000001d0000 08:07 6520995
>  /usr/X11R6/lib/libX11.so.6.2
> 2000000000284000-200000000028c000 r-xp 0000000000000000 08:07 6094863
>  /lib/libdl-2.2.4.so
> 200000000028c000-2000000000294000 ---p 0000000000008000 08:07 6094863
>  /lib/libdl-2.2.4.so
> 2000000000294000-200000000029c000 rw-p 0000000000000000 08:07 6094863
>  /lib/libdl-2.2.4.so
> 200000000029c000-20000000002b8000 r-xp 0000000000000000 08:07 6094883
>  /lib/libpthread-0.9.so
> 20000000002b8000-20000000002bc000 ---p 000000000001c000 08:07 6094883
>  /lib/libpthread-0.9.so
> 20000000002bc000-20000000002d4000 rw-p 0000000000010000 08:07 6094883
>  /lib/libpthread-0.9.so
> 20000000002d4000-2000000000358000 r-xp 0000000000000000 08:07 376886
>  /usr/lib/libncurses.so.5.2
> 2000000000358000-2000000000364000 ---p 0000000000084000 08:07 376886
>  /usr/lib/libncurses.so.5.2
> 2000000000364000-2000000000374000 rw-p 0000000000080000 08:07 376886
>  /usr/lib/libncurses.so.5.2
> 2000000000374000-2000000000378000 rw-p 0000000000000000 00:00 0
> 2000000000378000-2000000000400000 r-xp 0000000000000000 08:07 6094865
>  /lib/libm-2.2.4.so
> 2000000000400000-2000000000408000 ---p 0000000000088000 08:07 6094865
>  /lib/libm-2.2.4.so
> 2000000000408000-2000000000414000 rw-p 0000000000080000 08:07 6094865
>  /lib/libm-2.2.4.so
> 2000000000414000-200000000065c000 r-xp 0000000000000000 08:07 6094859
>  /lib/libc-2.2.4.so
> 200000000065c000-2000000000664000 ---p 0000000000248000 08:07 6094859
>  /lib/libc-2.2.4.so
> 2000000000664000-2000000000678000 rw-p 0000000000240000 08:07 6094859
>  /lib/libc-2.2.4.so
> <------------------------------------------------------------------------------------------->
>
> example /lib/libc-2.2.4.so size 6094859    got mapped 3 times with
> permissions 'r-xp' , '---p' and 'rw-p' from the bottom.
>

Looks okay. Several different offsets are mapped with different
permissions.

> I found the similar mappings for all the programs running on a IA-64
> machine. Is this some special kernel kind of feature on IA-64 ??
>

Same features on ix86....

08048000-08050000 r-xp 00000000 03:01 1392661    /sbin/init
08050000-08051000 rw-p 00008000 03:01 1392661    /sbin/init
08051000-08072000 rw-p 08051000 00:00 0          [heap]
4a956000-4a96b000 r-xp 00000000 03:01 9371722    /lib/ld-2.3.3.so
4a96b000-4a96c000 r--p 00014000 03:01 9371722    /lib/ld-2.3.3.so
4a96c000-4a96d000 rw-p 00015000 03:01 9371722    /lib/ld-2.3.3.so
4a973000-4aa88000 r-xp 00000000 03:01 9371733    /lib/tls/libc-2.3.3.so
4aa88000-4aa8a000 r--p 00115000 03:01 9371733    /lib/tls/libc-2.3.3.so
4aa8a000-4aa8c000 rw-p 00117000 03:01 9371733    /lib/tls/libc-2.3.3.so
4aa8c000-4aa8e000 rw-p 4aa8c000 00:00 0
4bbfd000-4bc0b000 r-xp 00000000 03:01 9371763    /lib/libselinux.so.1
4bc0b000-4bc0d000 rw-p 0000d000 03:01 9371763    /lib/libselinux.so.1
b7f03000-b7f04000 rw-p b7f03000 00:00 0
bfa0d000-bfa23000 rw-p bfa0d000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]

.... just doesn't look so enormous!


> Your kind inputs on this problem are greatly appreciated.
>
> Looking forward to hear from you.
>
> Thanks in advance,
> Vamsi kundeti
> -

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.