From: Toon Moene <toon@moene.org>
To: linux-newbie@vger.kernel.org
Subject: How to measure the effect of huge pages ?
Date: Tue, 26 Apr 2011 19:26:55 +0200 [thread overview]
Message-ID: <4DB7005F.1000408@moene.org> (raw)
Hi,
This would be more appropriate to a linux-help mailing list (which
doesn't exist), as I think I do understand the kernel issues involved,
but I do not see the effect I expect to see.
A week ago I updated Debian Testing - one of the packages updated was
the Linux kernel, which went from 2.6.32.n to 2.6.38.2:
$ uname -a
Linux super 2.6.38-2-amd64 #1 SMP Thu Apr 7 04:28:07 UTC 2011 x86_64
GNU/Linux
Now, 2.6.38 has anonymous (transparent) huge page support:
$ cat /proc/meminfo
...
AnonHugePages: 2484224 kB
So shortly (30 seconds) after rebooting, I did:
$ echo always >/sys/kernel/mm/transparent_hugepage/enabled
$ echo always >/sys/kernel/mm/transparent_hugepage/defrag
which is still in effect:
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
$ cat /sys/kernel/mm/transparent_hugepage/defrag
[always] madvise never
There's 4 Gbyte of RAM on this machine, and /proc/cpuinfo gives:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
stepping : 11
cpu MHz : 2394.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
vnmi flexpriority
bogomips : 4799.67
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
(4 times, for each core).
This is the main application (which fills the machine 4 times / day, 16
hours / day):
$ ps uxww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
hirlam 5528 0.0 0.0 56080 1492 ? S 17:35 0:01 mpirun
--mca mpi_paffinity_alone 1 --mca mpi_yield_when_idle 1 -np 4
/scratch/hirlam/hl_home/MPI/lib/src/linuxgfortranmpi/bin/hlprog.x
hirlam 5529 98.0 17.8 1090948 725416 ? R 17:35 99:42
/scratch/hirlam/hl_home/MPI/lib/src/linuxgfortranmpi/bin/hlprog.x
hirlam 5530 99.1 16.8 1091748 683932 ? R 17:35 100:50
/scratch/hirlam/hl_home/MPI/lib/src/linuxgfortranmpi/bin/hlprog.x
hirlam 5531 98.8 16.8 1086800 682432 ? R 17:35 100:34
/scratch/hirlam/hl_home/MPI/lib/src/linuxgfortranmpi/bin/hlprog.x
hirlam 5532 98.5 16.9 1093752 686796 ? R 17:35 100:16
/scratch/hirlam/hl_home/MPI/lib/src/linuxgfortranmpi/bin/hlprog.x
...
One would think such an application, which takes about 70 % of RAM would
be a prime example of one that gets a speed-up from huge pages.
However, the change in running time was unmeasurable.
Now, /proc/meminfo above shows that the huge pages *are* allocated, and
the only reasonable way they are is that they are allocated to *this*
application (I also see their allocation drop after the application
finishes).
What do I have to do to determine why this doesn't have the desired
effect ? Does (ordinary) malloc/free play a role ? What other system
parameters can I study to get a handle on this ?
Thanks for any insight you can offer.
--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
reply other threads:[~2011-04-26 17:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DB7005F.1000408@moene.org \
--to=toon@moene.org \
--cc=linux-newbie@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).