linux-numa.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Max Laier <max@laiers.net>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: linux-numa@vger.kernel.org
Subject: Re: alloc_pages_node(... GFP_KERNEL | GFP_THISNODE ...) fails
Date: Fri, 29 May 2009 03:09:32 +0200	[thread overview]
Message-ID: <200905290309.33194.max@laiers.net> (raw)
In-Reply-To: <alpine.DEB.1.10.0905282043390.32466@gentwo.org>

On Friday 29 May 2009 02:46:57 Christoph Lameter wrote:
> On Thu, 28 May 2009, Christoph Lameter wrote:
> > I'm having a bit of trouble with the NUMA allocator in the kernel. 
> > This is in a numa=fake test-setup (though this shouldn't matter, I
> > guess).
>
> Not sure how fake numa works. This could affect the result. page_to_nid

Simply by giving "numa=fake=256,256*" as a boot option I get several nodes 
of 256M each - seemed the easiest way to go for testing.  It's setup from 
arch/x86/mm/numa_64.c::numa_emulation and I didn't spot any obvious 
difference in the setup compared to the hardware detection.  I do have a 
box with k8 NUMA, but unfortunately no KVM support.  Again, remember that 
my test module works flawlessly.

My first reaction was that there must be something in the context that 
affects the allocation (waiting not allowed or some such), but I couldn't 
find anything like this in the call path.

> shows a different number than the node from which the page actually
> came? Sounds broken.
>
> > node 7 - "numactl --hardware" doesn't show any allocations from node
> > 7. In fact it seems that the memory is allocated from the first node
> > with free pages until these run out.  Only then pages from the
> > selected (last) node are given out.  Once the selected node is full,
> > alloc_pages_node(... GFP_THISNODE ...) returns NULL - as it should -
> > and I fall back to a normal allocation that then also reports a
> > different node ID from page_to_nid (c.f. the attached diff).
> >
> > The strange thing is, that a simple test module (attached as well)
> > works as expected.  The allocation succeeds, reports the selected
> > node in page_to_nid *and* the free memory reported from "numactl
> > --hardware" in the selected node decreases.
> >
> > Any insight as to why the KVM allocation might be special are very
> > appreciated.  I tried to follow the call path, but didn't find any
> > red flags that would indicate the difference.
>
> Please verify your numbers using /proc/zoneinfo.

Same result.  "numa_hit" in node 7 increases, while "nr_free_pages" stays 
the same.  Anything else you'd want me to watch out for?

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News


  reply	other threads:[~2009-05-29  1:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-29  0:30 alloc_pages_node(... GFP_KERNEL | GFP_THISNODE ...) fails Max Laier
     [not found] ` <f568093c0905281743i63e1a24ak681df87bc83826ce@mail.gmail.com>
2009-05-29  0:46   ` Christoph Lameter
2009-05-29  1:09     ` Max Laier [this message]
2009-05-29 13:54       ` Christoph Lameter
2009-05-29 15:01         ` Andi Kleen
2009-05-29 16:18           ` Max Laier
2009-05-29 16:36             ` Andi Kleen
2009-05-29 16:45               ` Max Laier
2009-05-29 18:26                 ` Andi Kleen
2009-05-29 20:39                   ` Max Laier
2009-06-02 20:13                     ` Andi Kleen
2009-06-02 22:59                     ` David Rientjes
2009-06-03 14:04                       ` Christoph Lameter
2009-06-03 18:24                         ` David Rientjes
2009-06-14  4:50                           ` Max Laier

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=200905290309.33194.max@laiers.net \
    --to=max@laiers.net \
    --cc=cl@linux-foundation.org \
    --cc=linux-numa@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 NNTP newsgroup(s).