Re: Slowdown with randomize_va_space in 2.6.12.2

Quoting "David S. Miller" <davem@xxxxxxxxxxxxx>:

> From: Andrew Morton <akpm@xxxxxxxx>
> Date: Wed, 6 Jul 2005 18:12:20 -0700
> 
> > ouch.   What do we do?  Default to off?  Default to off on xmeta?
> 
> Good question.  Whatever security is gained by the va randomization
> stuff is definitely not worth a 0.23 --> 3.0 second performance
> regression.

Well, I tested the exact same script on my P4 2.8GHz and didn't notice a
significant regression. So maybe this is really Transmeta specific.

Also, this workload probably represents the worst scenario to trigger this: the
script does more than 100 fork / execs with each exec'ed program doing very
little work and exiting.

I can do some more tests (tomorrow) to see if different workloads are also
significantly affected, but I suspect that simply running one "normal" process
(or a few) will not show this problem.

Anyway, I still find this to be a little weird. My understanding of the Linux
memory management is still limited, so correct me if I'm wrong:

 - once we exec one program for the first time, the executable file is mmap'ed
in memory and pages are faulted in as they are executed (modulo prefaulting,
read-ahead, etc.).

 - these same pages are kept as pagecache even after the process exits(*)

 - on the next execution, these pages are already in memory as pagecache, and
are simply mapped to the process address space. The virtual address is
different because of randomization, but the physical addresses are the same.

 - why does the Transmeta interpreter "re-compiles" the code that is on the same
physical address? Interpreter bug?

I'm just pointing this out, because the machine I'm working on isn't exactly
"new", and it might have an old version of the interpreter. This can possibly
mean that newer Transmetas might not show this problem at all.

This is the cpuinfo of the machine in question:

processor       : 0
vendor_id       : GenuineTMx86
cpu family      : 6
model           : 4
model name      : Transmeta(tm) Crusoe(tm) Processor TM5600
stepping        : 3
cpu MHz         : 530.696
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 sep cmov mmx longrun lrti
bogomips        : 1028.09

and the relevant part of the dmesg output:

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 512K (128 bytes/line)
CPU: Processor revision 1.3.1.2, 533 MHz
CPU: Code Morphing Software revision 4.2.7-8-278
CPU: 20011004 02:04 official release 4.2.7#7
CPU serial number disabled.
CPU: After all inits, caps: 0080893f 0081813f 0000000e 00000000 00000000
00000000 00000000
CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 stepping 03

So, if there is someone out there with newer Transmetas available that also want
to test this to see if there is a regression, I can build a small testcase to
see how it goes.

--
Paulo Marques - www.grupopie.com

(*) by the way, during the tests the machine always had more than 70Mb of free
memory, so I see no reason for it to dump pagecache

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/