From: "Max Laier" <max@laiers.net>
To: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Lameter <cl@linux-foundation.org>,
linux-numa@vger.kernel.org, David Rientjes <rientjes@google.com>
Subject: Re: alloc_pages_node(... GFP_KERNEL | GFP_THISNODE ...) fails
Date: Fri, 29 May 2009 22:39:45 +0200 [thread overview]
Message-ID: <25152b734413b689c1062d16d1b3356b.squirrel@mlaier.homeunix.org> (raw)
In-Reply-To: <20090529182649.GZ1065@one.firstfloor.org>
Am Fr, 29.05.2009, 20:26, schrieb Andi Kleen:
>> No, the test module is fine. The exact same call in the KVM allocation
>> routine, however, does not work. Again, please see my initial post.
>
> Sorry I don't have time to reverse engineer/debug your patches.
>
> If you can't state the problem clearly there's probably no way
> other people can help you on the mailing list.
I'm sorry if I sounded snippy, this wasn't intended. I hope I haven't
pissed away your good will yet - which is indeed greatly appreciated. So
let me try again to be more precise in specifying my problem:
I'm trying to replace a call to alloc_page() with alloc_pages_node() in
order to membind the allocation to a specific node set. This seemed to
work - as page_to_nid() returns the selected node. However, the free
memory in that node isn't decreasing.
I tried to build a test module to recreate the problem, but the test
module doesn't exhibit the bug. I assume that is because there is
something different with the context from which the allocation is
happening. I tried to follow the code path of alloc_pages_node() to find
out what that difference might be, but didn't succeed. Hence I attached a
boiled down version of my changes that still demonstrate the problem.
It's really a one line change in kvm.
I was hoping that someone with real numa hardware and kvm capabilities
would be able to test this tiny patch in order to find out if the problem
lies with the fake numa or indeed the context of the allocation so I could
focus my efforts on the right target.
Alternatively, I'd also be greatful if anybody had any idea why
alloc_pages_node() would behave differently in different context and what
that difference would be.
Again, sorry if I sounded ungreatful. I do appreciate any help or
pointers you could give me. I don't expect a final sollution and am
willing and ready to invest more time of my own to fixing this. I just
need some idea in which direction to go: fake numa or context.
Thanks.
--
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
next prev parent reply other threads:[~2009-05-29 20:39 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
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 [this message]
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=25152b734413b689c1062d16d1b3356b.squirrel@mlaier.homeunix.org \
--to=max@laiers.net \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=linux-numa@vger.kernel.org \
--cc=rientjes@google.com \
/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).