From: Oliver Weihe <o.weihe@deltacomputer.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: NUMA allocator on Opteron systems does non-local allocation on node0
Date: Mon, 13 Oct 2008 17:27:26 +0200 (CEST) [thread overview]
Message-ID: <5555373.1223911646283.SLOX.WebMail.wwwrun@exchange.deltacomputer.de> (raw)
In-Reply-To: <20081013104622.GK12131@one.firstfloor.org>
Hello,
it seems that my reproducer is not very good. :(
It "works" much better when you start several processes at once.
for i in `seq 0 3`
do
numactl --cpunodebind=${i} ./app &
done
wait
"app" still allocates some memory (7GiB per process) and fills the array
with data.
I've noticed this behaviour during some HPL (Linpack benchmark from/for
top500.org) runs. For small data sets there's no difference in speed
between the kernels while for big data sets (allmost the whole memory)
2.6.23 and newer kernels are slower than 2.6.22.
I'm using OpenMPI with the runtime option "--mca mpi_paffinity_alone 1"
to pin each process on a specific CPU.
The bad news is: I can crash allmost every Quadcore Opteron system with
kernels 2.6.21.x to 2.6.24.x with "parallel memory allocation and
filling the memory with data" (parallel means: there is one process per
core doing this). While it takes some time on dualsocket machines it
takes often less than 1 minute on quadsocket quadcores until the system
freezes.
Yust for the case it is some vendor specific BIOS bug: we're using
supermicro mainboards.
> [Another copy of the reply with linux-kernel added this time]
>
> > In my setup I'm allocating an array of ~7GiB memory size in a
> > singlethreaded application.
> > Startup: numactl --cpunodebind=X ./app
> > For X=1,2,3 it works as expected, all memory is allocated on the
> > local
> > node.
> > For X=0 I can see the memory beeing allocated on node0 as long as
> > ~3GiB
> > are "free" on node0. At this point the kernel starts using memory
> > from
> > node1 for the app!
>
> Hmm, that sounds like it doesn't want to use the 4GB DMA zone.
>
> Normally there should be no protection on it, but perhaps something
> broke.
>
> What does cat /proc/sys/owmem_reserve_ratio say?
2.6.22.x:
# cat /proc/sys/vm/lowmem_reserve_ratio
256 256
2.6.23.8 (and above)
# cat /proc/sys/vm/lowmem_reserve_ratio
256 256 32
> > For parallel realworld apps I've seen a performance penalty of 30%
> > compared to older kernels!
>
> Compared to what older kernels? When did it start?
I've tested some kernel Versions that I've laying around here...
working fine: 2.6.22.18-0.2-default (openSUSE) / 2.6.22.9 (kernel.org)
showing the described behaviour: 2.6.23.8; 2.6.24.4; 2.6.25.4; 2.6.26.5;
2.6.27
>
> -Andi
>
> --
> ak@linux.intel.com
>
--
Regards,
Oliver Weihe
next prev parent reply other threads:[~2008-10-13 15:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 10:46 Andi Kleen
2008-10-13 15:27 ` Oliver Weihe [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-10-13 10:15 Oliver Weihe
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=5555373.1223911646283.SLOX.WebMail.wwwrun@exchange.deltacomputer.de \
--to=o.weihe@deltacomputer.de \
--cc=andi@firstfloor.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®