Re: [discuss] mmap, mbind and write to mmap'ed memory crashes 2.6.16-rc1[2] on 2 node X86_64
From: Andi Kleen
Date: Thu Feb 09 2006 - 05:00:19 EST
On Thursday 09 February 2006 05:39, Bharata B Rao wrote:
> On Wed, Feb 08, 2006 at 05:06:26PM +0100, Andi Kleen wrote:
> > On Wednesday 08 February 2006 16:59, Christoph Lameter wrote:
> > > On Wed, 8 Feb 2006, Andi Kleen wrote:
> > >
> > > > On Wednesday 08 February 2006 16:42, Christoph Lameter wrote:
> > > >
> > > > > However, this has implications for policy_zone. This variable should store
> > > > > the zone that policies apply to. However, in your case this zone will vary
> > > > > which may lead to all sorts of weird behavior even if we fix
> > > > > bind_zonelist. To which zone does policy apply? ZONE_NORMAL or ZONE_DMA32?
> > > >
> > > > It really needs to apply to both (currently you can't police 4GB of your
> > > > memory on x86-64) But I haven't worked out a good design how to implement it yet.
> > >
> > > So a provisional solution would be to simply ignore empty zones in
> > > bind_zonelist?
> >
> > That would likely prevent the crash yes (Bharata can you test?)
>
> With this solution, the kernel doesn't crash, but the application does.
>
> Shouldn't we fail mbind if we can't bind any zones ?
Really need to fix this properly to support both zones in mbind
> Does it make sense to have a separate policy_zone for each node so that we
> have atleast one(highest) zone in a node which comes under memory policy ?
That wouldn't solve the problem. The problem is that the mempolicy needs
at least two zonelists to handle all type of allocations (that is why
i added the concept of policy zone in the first place - to avoid the need
of multilevel zonelists in the policies)
Or maybe it's better to just don't do any policy for GFP_DMA32
allocations and always use the highest zonelist. I guess they're somewhat
rare anyways and the policy will rarely succeed.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/