All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Kautuk Consul <consul.kautuk@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH] ARM: sparsemem: Enable CONFIG_HOLES_IN_ZONE config option for SparseMem and HAS_HOLES_MEMORYMODEL for linux-3.0.
Date: Wed, 3 Aug 2011 12:05:55 +0100	[thread overview]
Message-ID: <20110803110555.GD19099@suse.de> (raw)
In-Reply-To: <CAFPAmTQByL0YJT8Lvar1Oe+3Q1EREvqPA_GP=hHApJDz5dSOzQ@mail.gmail.com>

On Tue, Aug 02, 2011 at 05:38:31PM +0530, Kautuk Consul wrote:
> Hi,
> 
> In the case where the total kernel memory is not aligned to the
> SECTION_SIZE_BITS I see a kernel crash.
> 
> When I copy a huge file, then the kernel crashes at the following callstack:
> 

The callstack should not be 80-column formatted as this is completely
manged and unreadable without manual editting. Also, why did you not
include the full error message? With it, I'd have a better idea of
which bug check you hit.

> Backtrace:
> <SNIP>
> 
> The reason for this is that the CONFIG_HOLES_IN_ZONE configuration
> option is not automatically enabled when SPARSEMEM or
> ARCH_HAS_HOLES_MEMORYMODEL are enabled. Due to this, the
> pfn_valid_within() macro always returns 1 due to which the BUG_ON is
> encountered.
> This patch enables the CONFIG_HOLES_IN_ZONE config option if either
> ARCH_HAS_HOLES_MEMORYMODEL or SPARSEMEM is enabled.
> 
> Although I tested this on an older kernel, i.e., 2.6.35.13, I see that
> this option has not been enabled as yet in linux-3.0 and this appears
> to be a
> logically correct change anyways with respect to pfn_valid_within()
> functionality.
> 

There is a performance cost associated with HOLES_IN_ZONE which may be
offset by memory savings but not necessarily.

If the BUG_ON you are hitting is this one
BUG_ON(page_zone(start_page) != page_zone(end_page)) then I'd be
wondering why the check in move_freepages_block() was insufficient.

If it's because holes are punched in the memmap then the option does
need to be set.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: mgorman@suse.de (Mel Gorman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: sparsemem: Enable CONFIG_HOLES_IN_ZONE config option for SparseMem and HAS_HOLES_MEMORYMODEL for linux-3.0.
Date: Wed, 3 Aug 2011 12:05:55 +0100	[thread overview]
Message-ID: <20110803110555.GD19099@suse.de> (raw)
In-Reply-To: <CAFPAmTQByL0YJT8Lvar1Oe+3Q1EREvqPA_GP=hHApJDz5dSOzQ@mail.gmail.com>

On Tue, Aug 02, 2011 at 05:38:31PM +0530, Kautuk Consul wrote:
> Hi,
> 
> In the case where the total kernel memory is not aligned to the
> SECTION_SIZE_BITS I see a kernel crash.
> 
> When I copy a huge file, then the kernel crashes at the following callstack:
> 

The callstack should not be 80-column formatted as this is completely
manged and unreadable without manual editting. Also, why did you not
include the full error message? With it, I'd have a better idea of
which bug check you hit.

> Backtrace:
> <SNIP>
> 
> The reason for this is that the CONFIG_HOLES_IN_ZONE configuration
> option is not automatically enabled when SPARSEMEM or
> ARCH_HAS_HOLES_MEMORYMODEL are enabled. Due to this, the
> pfn_valid_within() macro always returns 1 due to which the BUG_ON is
> encountered.
> This patch enables the CONFIG_HOLES_IN_ZONE config option if either
> ARCH_HAS_HOLES_MEMORYMODEL or SPARSEMEM is enabled.
> 
> Although I tested this on an older kernel, i.e., 2.6.35.13, I see that
> this option has not been enabled as yet in linux-3.0 and this appears
> to be a
> logically correct change anyways with respect to pfn_valid_within()
> functionality.
> 

There is a performance cost associated with HOLES_IN_ZONE which may be
offset by memory savings but not necessarily.

If the BUG_ON you are hitting is this one
BUG_ON(page_zone(start_page) != page_zone(end_page)) then I'd be
wondering why the check in move_freepages_block() was insufficient.

If it's because holes are punched in the memmap then the option does
need to be set.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2011-08-03 11:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02 12:08 [PATCH] ARM: sparsemem: Enable CONFIG_HOLES_IN_ZONE config option for SparseMem and HAS_HOLES_MEMORYMODEL for linux-3.0 Kautuk Consul
2011-08-02 12:08 ` Kautuk Consul
2011-08-03 11:05 ` Mel Gorman [this message]
2011-08-03 11:05   ` Mel Gorman
2011-08-03 12:29   ` Kautuk Consul
2011-08-03 12:29     ` Kautuk Consul
2011-08-03 13:28     ` Mel Gorman
2011-08-03 13:28       ` Mel Gorman
2011-08-04  9:36       ` Kautuk Consul
2011-08-04  9:36         ` Kautuk Consul
2011-08-04 10:09         ` Mel Gorman
2011-08-04 10:09           ` Mel Gorman
2011-08-05  5:57           ` Kautuk Consul
2011-08-05  5:57             ` Kautuk Consul
2011-08-05  8:47             ` Mel Gorman
2011-08-05  8:47               ` Mel Gorman
2011-08-05 11:40               ` Kautuk Consul
2011-08-05 11:40                 ` Kautuk Consul
2011-08-24 12:31                 ` Kautuk Consul

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=20110803110555.GD19099@suse.de \
    --to=mgorman@suse.de \
    --cc=consul.kautuk@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=rmk@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.