linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@skynet.ie>,
	davej@codemonkey.org.uk, tony.luck@intel.com,
	linuxppc-dev@ozlabs.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	bob.picco@hp.com,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
Date: Wed, 12 Apr 2006 18:08:48 -0700	[thread overview]
Message-ID: <1144890528.31255.97.camel@localhost.localdomain> (raw)
In-Reply-To: <200604130257.00203.ak@suse.de>

On Thu, 2006-04-13 at 02:56 +0200, Andi Kleen wrote:
> The problem is not memory consumption but complexity of code/data structures.
> Keeping information in two places is usually a good cue that something 
> is wrong. This code is also fragile and hard to test. 

Part of the motivation for these patches is that we really duplicate a
lot of functionality across architectures.  For instance, on x86, we
have limit_regions() to fiddle with the e820 or efi tables to make them
look right after a mem= on the command-line.

We end up doing the same kind of fiddling on powerpc, but on LMBs,
instead.  This code is error-prone, and every one of these
implementations gets it wrong.  I believe I've seen and fixed bugs in at
least two of them.  Add in NUMA things or hotplug boot-time zone sizing,
and you get an even worse mess. 

The motivation for Mel's patches is to keep the architectures from
getting it wrong.  If we let them do it themselves, they _will_ get it
wrong, and any bugfixes will not help anybody else.

If we do it in common code, we will certainly have bugs for a while.  By
sharing code, we narrow the bugs down to one place, and only have to fix
them once.

-- Dave "guy who hates the same bugs in many arches" Hansen

--
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:[~2006-04-13  1:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-12 23:20 [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2 Mel Gorman
2006-04-12 23:20 ` [PATCH 1/7] Introduce mechanism for registering active regions of memory Mel Gorman
2006-04-12 23:21 ` [PATCH 2/7] Have Power use add_active_range() and free_area_init_nodes() Mel Gorman
2006-04-12 23:21 ` [PATCH 3/7] Have x86 use add_active_range() and free_area_init_nodes Mel Gorman
2006-04-12 23:21 ` [PATCH 4/7] Have x86_64 " Mel Gorman
2006-04-12 23:22 ` [PATCH 5/7] Have ia64 " Mel Gorman
2006-04-12 23:22 ` [PATCH 6/7] Break out memory initialisation code from page_alloc.c to mem_init.c Mel Gorman
2006-04-12 23:22 ` [PATCH 7/7] Print out debugging information during initialisation Mel Gorman
2006-04-12 23:53 ` [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2 Andi Kleen
2006-04-13  0:22   ` Mel Gorman
2006-04-13  0:56     ` Andi Kleen
2006-04-13  1:08       ` Dave Hansen [this message]
2006-04-13 10:24       ` Mel Gorman
2006-04-13  9:52 ` Mel Gorman
2006-04-13 10:32   ` Yasunori Goto
2006-04-13 10:51     ` Mel Gorman
2006-04-13 17:19   ` Luck, Tony
2006-04-13 17:30     ` Mel Gorman
2006-04-13 17:47       ` Luck, Tony
2006-04-13 19:14         ` Mel Gorman
2006-04-13 21:53           ` Luck, Tony
2006-04-14 13:12             ` Mel Gorman
2006-04-14 20:53               ` Luck, Tony
2006-04-14 22:54                 ` Mel Gorman
2006-04-14 23:17 ` Nigel Cunningham
2006-04-14 23:50   ` 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=1144890528.31255.97.camel@localhost.localdomain \
    --to=haveblue@us.ibm.com \
    --cc=ak@suse.de \
    --cc=bob.picco@hp.com \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mel@skynet.ie \
    --cc=tony.luck@intel.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;
as well as URLs for NNTP newsgroup(s).