public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed

From: tangchen@cn•fujitsu.com (Tang Chen)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add node/memory case
Date: Thu, 11 Apr 2013 15:41:36 +0800	[thread overview]
Message-ID: <51666930.6090702@cn.fujitsu.com> (raw)
In-Reply-To: <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>

Hi Yinghai,

(Add cc Liu Jiang.)

On 04/09/2013 02:40 AM, Yinghai Lu wrote:
> On Mon, Apr 8, 2013 at 2:56 AM, Lin Feng<linfeng@cn•fujitsu.com>  wrote:
>> In hot add node(memory) case, vmemmap pages are always allocated from other
>> node,
>
> that is broken, and should be fixed.
> vmemmap should be on local node even for hot add node.
>

I want some info sharing. :)

Here is the work I'm trying to do.

1. As most of people don't like movablemem_map idea, we decide to
    drop "specifying physical address" thing, and restart a new solution
    to support using SRAT info only.

    We want to modify movablecore to support "movablecore=acpi" to
    enable/disable limiting hotpluggable memory in ZONE_MOVABLE.
    And we dropped all the old design and data structures.

2. As Liu Jiang mentioned before, we can add a flag to memblock to mark
    special memory. Since we are dropping all the old data structures,
    I think I want to reuse his idea to reserve movable memory with memblock
    when booting.

3. If we add flag to memblock, we can mark different memory. And I remember
    you mentioned before that we can use memblock to reserve local node 
data
    for node-life-cycle data, like vmemmap, pagetable.

    So are you doing the similar work now ?

    If not, I think I can merge it into mine, and push a new patch-set with
    hot-add, hot-remove code modified to support putting vmemmap, 
pagetable,
    pgdat, page_cgroup, ..., on local node.

    If you are doing the similar work, I will only finish my work and wait
    for your patch.

Thanks. :)

next prev parent reply	other threads:[~2013-04-11  7:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08  9:56 [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add node/memory case Lin Feng
2013-04-08  9:56 ` [PATCH 1/2] mm: vmemmap: x86: add vmemmap_verify check for hot-add node case Lin Feng
2013-04-08 10:23   ` Lin Feng
2013-04-08  9:56 ` [PATCH 2/2] mm: vmemmap: arm64: " Lin Feng
2013-04-08 10:55   ` Will Deacon
2013-04-09  2:07     ` Lin Feng
2013-04-08 18:40 ` [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add node/memory case Yinghai Lu
2013-04-08 20:55   ` Andrew Morton
2013-04-09  1:58     ` Lin Feng
2013-04-09  2:02   ` Lin Feng
2013-04-11  7:41   ` Tang Chen [this message]
2013-04-11 15:10     ` Yinghai Lu
2013-04-12  1:13       ` Tang Chen

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=51666930.6090702@cn.fujitsu.com \
    --to=tangchen@cn$(echo .)fujitsu.com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox