All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: akpm@osdl.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	hch@infradead.org, linuxppc-dev@ozlabs.org, paulus@samba.org,
	mkravetz@us.ibm.com, gone@us.ibm.com, cbe-oss-dev@ozlabs.org
Subject: Re: [PATCH] Fix sparsemem on Cell
Date: Sat, 16 Dec 2006 07:21:53 +1100	[thread overview]
Message-ID: <1166214113.31351.101.camel@localhost.localdomain> (raw)
In-Reply-To: <20061215165335.61D9F775@localhost.localdomain>


> The only other assumption is that all memory-hotplug-time pages 
> given to memmap_init_zone() are valid and able to be onlined into
> any any zone after the system is running.  The "valid" part is
> really just a question of whether or not a 'struct page' is there
> for the pfn, and *not* whether there is actual memory.  Since
> all sparsemem sections have contiguous mem_map[]s within them,
> and we only memory hotplug entire sparsemem sections, we can
> be confident that this assumption will hold.
> 
> As for the memory being in the right node, we'll assume tha
> memory hotplug is putting things in the right node.

BTW, just that people know, what we are adding isn't even memory :-) We
are calling __add_pages() to create struct page for the SPE local stores
and register space as we use them later from a nopage() handler (and no,
we can't use no_pfn just yet for various reasons, notably we need to
handle races with unmap_mapping_ranges() and thus have the truncate
logic in).

Those pages, thus, must never be onlined. Ever. It might make sense to
create a way to inform memory hotplug of that fact, but on the other
hand, I wouldn't bother as I have a plan to get rid of those
__add_pages() completely and work without struct page, maybe in a 2.6.21
timeframe.

Ben.

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org,
	linux-mm@kvack.org, apw@shadowen.org, mkravetz@us.ibm.com,
	hch@infradead.org, jk@ozlabs.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org, paulus@samba.org, gone@us.ibm.com
Subject: Re: [PATCH] Fix sparsemem on Cell
Date: Sat, 16 Dec 2006 07:21:53 +1100	[thread overview]
Message-ID: <1166214113.31351.101.camel@localhost.localdomain> (raw)
In-Reply-To: <20061215165335.61D9F775@localhost.localdomain>


> The only other assumption is that all memory-hotplug-time pages 
> given to memmap_init_zone() are valid and able to be onlined into
> any any zone after the system is running.  The "valid" part is
> really just a question of whether or not a 'struct page' is there
> for the pfn, and *not* whether there is actual memory.  Since
> all sparsemem sections have contiguous mem_map[]s within them,
> and we only memory hotplug entire sparsemem sections, we can
> be confident that this assumption will hold.
> 
> As for the memory being in the right node, we'll assume tha
> memory hotplug is putting things in the right node.

BTW, just that people know, what we are adding isn't even memory :-) We
are calling __add_pages() to create struct page for the SPE local stores
and register space as we use them later from a nopage() handler (and no,
we can't use no_pfn just yet for various reasons, notably we need to
handle races with unmap_mapping_ranges() and thus have the truncate
logic in).

Those pages, thus, must never be onlined. Ever. It might make sense to
create a way to inform memory hotplug of that fact, but on the other
hand, I wouldn't bother as I have a plan to get rid of those
__add_pages() completely and work without struct page, maybe in a 2.6.21
timeframe.

Ben.



WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org,
	linux-mm@kvack.org, apw@shadowen.org, mkravetz@us.ibm.com,
	hch@infradead.org, jk@ozlabs.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org, paulus@samba.org, gone@us.ibm.com
Subject: Re: [PATCH] Fix sparsemem on Cell
Date: Sat, 16 Dec 2006 07:21:53 +1100	[thread overview]
Message-ID: <1166214113.31351.101.camel@localhost.localdomain> (raw)
In-Reply-To: <20061215165335.61D9F775@localhost.localdomain>

> The only other assumption is that all memory-hotplug-time pages 
> given to memmap_init_zone() are valid and able to be onlined into
> any any zone after the system is running.  The "valid" part is
> really just a question of whether or not a 'struct page' is there
> for the pfn, and *not* whether there is actual memory.  Since
> all sparsemem sections have contiguous mem_map[]s within them,
> and we only memory hotplug entire sparsemem sections, we can
> be confident that this assumption will hold.
> 
> As for the memory being in the right node, we'll assume tha
> memory hotplug is putting things in the right node.

BTW, just that people know, what we are adding isn't even memory :-) We
are calling __add_pages() to create struct page for the SPE local stores
and register space as we use them later from a nopage() handler (and no,
we can't use no_pfn just yet for various reasons, notably we need to
handle races with unmap_mapping_ranges() and thus have the truncate
logic in).

Those pages, thus, must never be onlined. Ever. It might make sense to
create a way to inform memory hotplug of that fact, but on the other
hand, I wouldn't bother as I have a plan to get rid of those
__add_pages() completely and work without struct page, maybe in a 2.6.21
timeframe.

Ben.


--
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>

  parent reply	other threads:[~2006-12-15 20:21 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-15 16:53 [PATCH] Fix sparsemem on Cell Dave Hansen
2006-12-15 16:53 ` Dave Hansen
2006-12-15 16:53 ` Dave Hansen
2006-12-15 17:11 ` Andy Whitcroft
2006-12-15 17:11   ` Andy Whitcroft
2006-12-15 17:11   ` Andy Whitcroft
2006-12-15 17:24   ` Dave Hansen
2006-12-15 17:24     ` Dave Hansen
2006-12-15 17:24     ` Dave Hansen
2006-12-15 19:45     ` Andrew Morton
2006-12-15 19:45       ` Andrew Morton
2006-12-15 19:45       ` Andrew Morton
2006-12-16  8:03       ` KAMEZAWA Hiroyuki
2006-12-16  8:03         ` KAMEZAWA Hiroyuki
2006-12-16  8:03         ` KAMEZAWA Hiroyuki
2006-12-18 21:13         ` Dave Hansen
2006-12-18 21:13           ` Dave Hansen
2006-12-18 21:13           ` Dave Hansen
2006-12-18 22:15           ` Christoph Hellwig
2006-12-18 22:15             ` Christoph Hellwig
2006-12-18 22:15             ` Christoph Hellwig
2006-12-18 22:54         ` Arnd Bergmann
2006-12-18 22:54           ` Arnd Bergmann
2006-12-18 22:54           ` Arnd Bergmann
2006-12-18 23:16           ` Dave Hansen
2006-12-18 23:16             ` Dave Hansen
2006-12-18 23:16             ` Dave Hansen
2006-12-19  0:16             ` KAMEZAWA Hiroyuki
2006-12-19  0:16               ` KAMEZAWA Hiroyuki
2006-12-19  0:16               ` KAMEZAWA Hiroyuki
2006-12-19  8:59             ` Arnd Bergmann
2006-12-19  8:59               ` Arnd Bergmann
2006-12-19  8:59               ` Arnd Bergmann
2006-12-19 19:34               ` Dave Hansen
2006-12-19 19:34                 ` Dave Hansen
2006-12-19 19:34                 ` Dave Hansen
2007-01-06  1:10               ` [PATCH] Fix sparsemem on Cell (take 3) Dave Hansen
2007-01-06  1:10                 ` Dave Hansen
2007-01-06  1:10                 ` Dave Hansen
2007-01-06  4:52                 ` John Rose
2007-01-06  4:52                   ` John Rose
2007-01-06  4:52                   ` John Rose
2007-01-07  8:58                   ` Dave Hansen
2007-01-07  8:58                     ` Dave Hansen
2007-01-07  8:58                     ` Dave Hansen
2007-01-07 12:07                     ` Arnd Bergmann
2007-01-07 12:07                       ` Arnd Bergmann
2007-01-07 12:07                       ` Arnd Bergmann
2007-01-08  6:31                     ` Tim Pepper
2007-01-08  6:31                       ` Tim Pepper
2007-01-08  6:47                     ` Tim Pepper
2007-01-08  6:47                       ` Tim Pepper
2007-01-08  6:47                       ` Tim Pepper
2006-12-15 17:22 ` [PATCH] Fix sparsemem on Cell Michael Buesch
2006-12-15 17:22   ` Michael Buesch
2006-12-15 17:22   ` Michael Buesch
2006-12-15 17:57   ` Dave Hansen
2006-12-15 17:57     ` Dave Hansen
2006-12-15 17:57     ` Dave Hansen
2006-12-15 20:21 ` Benjamin Herrenschmidt [this message]
2006-12-15 20:21   ` Benjamin Herrenschmidt
2006-12-15 20:21   ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2006-12-15 17:14 Dave Hansen
2006-12-15 17:14 ` Dave Hansen
2006-12-15 17:14 ` Dave Hansen
2006-12-17 23:02 ` Arnd Bergmann
2006-12-17 23:02   ` Arnd Bergmann
2006-12-17 23:02   ` Arnd Bergmann

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=1166214113.31351.101.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=gone@us.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mkravetz@us.ibm.com \
    --cc=paulus@samba.org \
    /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.