[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29495f1d0706261204x5b49511co18546443c78033fd@mail.gmail.com>
Date: Tue, 26 Jun 2007 12:04:18 -0700
From: "Nish Aravamudan" <nish.aravamudan@...il.com>
To: "Christoph Lameter" <clameter@....com>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
"Paul Mundt" <lethal@...ux-sh.org>,
"Matt Mackall" <mpm@...enic.com>,
"Nick Piggin" <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] slob: poor man's NUMA support.
On 6/26/07, Christoph Lameter <clameter@....com> wrote:
> On Tue, 26 Jun 2007, Andrew Morton wrote:
>
> > > +#ifdef CONFIG_NUMA
> > > + if (node != -1)
> > > + page = alloc_pages_node(node, gfp, order);
> > > + else
> > > +#endif
> > > + page = alloc_pages(gfp, order);
> >
> > Isn't the above equivalent to a bare
> >
> > page = alloc_pages_node(node, gfp, order);
> >
> > ?
>
> No. alloc_pages follows memory policy. alloc_pages_node does not. One of
> the reasons that I want a new memory policy layer are these kinds of
> strange uses.
What would break by changing, in alloc_pages_node()
if (nid < 0)
nid = numa_node_id();
to
if (nid < 0)
return alloc_pages_current(gfp_mask, order);
beyond needing to make alloc_pages_current() defined if !NUMA too.
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists