linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, mingo@elte.hu, linux-kernel@vger.kernel.org,
	clameter@sgi.com
Subject: Re: [PATCH 1/4] Add a basic debugging framework for memory initialisation
Date: Mon, 28 Apr 2008 10:34:26 +0100	[thread overview]
Message-ID: <20080428093426.GB3294@csn.ul.ie> (raw)
In-Reply-To: <20080425231028.cb4a57b1.akpm@linux-foundation.org>

On (25/04/08 23:10), Andrew Morton didst pronounce:
> > On Tue, 22 Apr 2008 19:31:53 +0100 (IST) Mel Gorman <mel@csn.ul.ie> wrote:
> >
> > This patch creates a new file mm/mm_init.c which is conditionally compiled
> > to have almost all of the debugging and verification code to avoid further
> > polluting page_alloc.c. Ideally other mm initialisation code will be moved
> > here over time and the file partially compiled depending on Kconfig.
> 
> I was wondering why the file was misnamed ;)
> 

:) I named it mm_debug.c at one point before figuring another attempt to
move the init code out of page_alloc.c might help make that file more
readable in the long term.

> I worry that
> 
> a) MM developers will forget to turn on the debug option (ask me about
>    this) and the code in mm_init.c will break and 
> 
> b) The mm_init.c code is broken (or will break) on some architecture(s)
>    and people who run that arch won't turn on the debug option either.
> 
> So hm.  I think that we should be more inclined to at least compile the
> code even if we don't run it.  To catch compile-time breakage.
> 

Ok, that seems fair as CONFIG_DEBUG_VM is probably not enabled a lot of the
time. I had slightly different concerns where it would compile fine, but the
verification code would be broken at runtime due to some change in the core
(zonelist handling for example) and not caught quickly. I will set this
to always build unless CONFIG_EMBEDDED in which case it iss optional. The
default logging level will be set to only print messages on errors. The
possibility will exist that a change later will cause compile-breakage on
CONFIG_EMBEDDED && !CONFIG_DEBUG_MEMORY_INIT.

Is this a reasonable approach?

> And it would be good if we could have a super-quick version of the checks
> just so that more people at least partially run them.  Or something.
> 

As it is, the checks should not cause noticable slowdown on boot. The
most common tests is the one run on each initialised struct page

+void __meminit mminit_verify_page_links(struct page *page, enum zone_type zone,
+                       unsigned long nid, unsigned long pfn)
+{
+       BUG_ON(page_to_nid(page) != nid);
+       BUG_ON(page_zonenum(page) != zone);
+       BUG_ON(page_to_pfn(page) != pfn);
+}

I doubt the overhead will be noticed.

If future expensive tests become, they could run conditionally depending
on the value of mminit_level=.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-04-28  9:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22 18:31 [PATCH 0/4] Verification and debugging of memory initialisation V3 Mel Gorman
2008-04-22 18:31 ` [PATCH 1/4] Add a basic debugging framework for memory initialisation Mel Gorman
2008-04-26  6:10   ` Andrew Morton
2008-04-28  9:34     ` Mel Gorman [this message]
2008-04-22 18:32 ` [PATCH 2/4] Verify the page links and memory model Mel Gorman
2008-04-22 18:32 ` [PATCH 3/4] Make defencive checks around PFN values registered for memory usage Mel Gorman
2008-04-22 18:32 ` [PATCH 4/4] Print out the zonelists on request for manual verification Mel Gorman
  -- strict thread matches above, loose matches on Subject: below --
2008-04-28 19:28 [PATCH 0/4] Verification and debugging of memory initialisation V4 Mel Gorman
2008-04-28 19:28 ` [PATCH 1/4] Add a basic debugging framework for memory initialisation Mel Gorman
2008-04-17  0:06 [PATCH 0/4] Verification and debugging of memory initialisation V2 Mel Gorman
2008-04-17  0:06 ` [PATCH 1/4] Add a basic debugging framework for memory initialisation Mel Gorman
2008-04-21 15:14   ` Ingo Molnar
2008-04-22 11:21     ` Mel Gorman
2008-04-16 13:50 [PATCH 0/4] [RFC] Verification and debugging of " Mel Gorman
2008-04-16 13:51 ` [PATCH 1/4] Add a basic debugging framework for " Mel Gorman
2008-04-16 14:04   ` Ingo Molnar
2008-04-16 19:30     ` Mel Gorman

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=20080428093426.GB3294@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    /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