public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@in.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Christoph Lameter <clameter@engr.sgi.com>,
	Ray Bryant <raybry@mpdtxmail.amd.com>,
	discuss@x86-64.org, linux-kernel@vger.kernel.org
Subject: Re: [discuss] mmap, mbind and write to mmap'ed memory crashes 2.6.16-rc1[2] on 2 node X86_64
Date: Thu, 9 Feb 2006 10:09:33 +0530	[thread overview]
Message-ID: <20060209043933.GA2986@in.ibm.com> (raw)
In-Reply-To: <200602081706.26853.ak@suse.de>

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 ?
Something like this...


Signed-off-by: Bharata B Rao <bharata@in.ibm.com>

--- linux-2.6.16-rc2/mm/mempolicy.c.orig	2006-02-09 01:34:37.000000000 -0800
+++ linux-2.6.16-rc2/mm/mempolicy.c	2006-02-09 01:39:32.000000000 -0800
@@ -143,8 +143,18 @@
 	if (!zl)
 		return NULL;
 	num = 0;
-	for_each_node_mask(nd, *nodes)
-		zl->zones[num++] = &NODE_DATA(nd)->node_zones[policy_zone];
+	for_each_node_mask(nd, *nodes) {
+		struct zone *zone = &NODE_DATA(nd)->node_zones[policy_zone];
+
+		if (zone->present_pages)
+			zl->zones[num++] = zone;
+	}
+
+	if (!num) {
+		/* failed to bind even a single zone */
+		kfree(zl);
+		return NULL;
+	}
 	zl->zones[num] = NULL;
 	return zl;
 }

> 
> But of course it still has the problem of a lot of memory being unpolicied
> on machines with >4GB if there's both DMA32 and NORMAL.
> 
> > Or fall back to earlier zones (which includes unpolicied  
> > zones in the bind zone list?)
> 

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 ?

Regards,
Bharata.

  parent reply	other threads:[~2006-02-09  4:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060205163618.GB21972@in.ibm.com>
2006-02-05 17:03 ` [discuss] mmap, mbind and write to mmap'ed memory crashes 2.6.16-rc1[2] on 2 node X86_64 Andi Kleen
2006-02-06 16:11   ` Christoph Lameter
2006-02-06 18:12     ` Andi Kleen
2006-02-06 18:25       ` Christoph Lameter
2006-02-06 18:31         ` Andi Kleen
2006-02-06 18:45           ` Christoph Lameter
2006-02-06 18:55             ` Andi Kleen
2006-02-06 19:22               ` Christoph Lameter
2006-02-07  5:59               ` Bharata B Rao
2006-02-07 16:49                 ` Christoph Lameter
2006-02-07 23:27                   ` Ray Bryant
2006-02-07 23:36                     ` Andi Kleen
2006-02-08 12:10                       ` Bharata B Rao
2006-02-08 15:42                         ` Christoph Lameter
2006-02-08 15:45                           ` Andi Kleen
2006-02-08 15:59                             ` Christoph Lameter
2006-02-08 16:06                               ` Andi Kleen
2006-02-08 16:20                                 ` Christoph Lameter
2006-02-08 16:27                                   ` Andi Kleen
2006-02-08 16:51                                     ` Christoph Lameter
2006-02-09  4:39                                 ` Bharata B Rao [this message]
2006-02-09  9:58                                   ` Andi Kleen
2006-02-14 19:33                                     ` Christoph Lameter
2006-02-15  5:46                                       ` Bharata B Rao
2006-02-15 10:38                                         ` Bharata B Rao
2006-02-15 11:21                                           ` Andi Kleen
2006-02-15 18:14                                             ` Christoph Lameter
2006-02-16  5:18                                             ` Bharata B Rao
2006-02-15 18:10                                           ` Christoph Lameter

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=20060209043933.GA2986@in.ibm.com \
    --to=bharata@in.ibm.com \
    --cc=ak@suse.de \
    --cc=clameter@engr.sgi.com \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raybry@mpdtxmail.amd.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