Date: Tue, 30 Jun 2015 12:46:54 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Xishi Qiu <qiuxishi@huawei.com>, Andrew Morton <akpm@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>, "Luck, Tony" <tony.luck@intel.com>,
        Hanjun Guo <guohanjun@huawei.com>, Xiexiuqi <xiexiuqi@huawei.com>,
        leon@leon.nu, Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
        Vlastimil Babka <vbabka@suse.cz>, Linux MM <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v2 PATCH 0/8] mm: mirrored memory support for page buddy
 allocations
Message-ID: <20150630104654.GA24932@gmail.com>
References: <558E084A.60900@huawei.com>
 <20150630094149.GA6812@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150630094149.GA6812@suse.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1705
Lines: 42


* Mel Gorman <mgorman@suse.de> wrote:

> [...]
> 
> Basically, overall I feel this series is the wrong approach but not knowing who 
> the users are making is much harder to judge. I strongly suspect that if 
> mirrored memory is to be properly used then it needs to be available before the 
> page allocator is even active. Once active, there needs to be controlled access 
> for allocation requests that are really critical to mirror and not just all 
> kernel allocations. None of that would use a MIGRATE_TYPE approach. It would be 
> alterations to the bootmem allocator and access to an explicit reserve that is 
> not accounted for as "free memory" and accessed via an explicit GFP flag.

So I think the main goal is to avoid kernel crashes when a #MC memory fault 
arrives on a piece of memory that is owned by the kernel.

In that sense 'protecting' all kernel allocations is natural: we don't know how to 
recover from faults that affect kernel memory.

We do know how to recover from faults that affect user-space memory alone.

So if a mechanism is in place that prioritizes 3 groups of allocators:

  - non-recoverable memory (kernel allocations mostly)

  - high priority user memory (critical apps that must never fail)

  - recoverable user memory (non-dirty caches that can simply be dropped,
    non-critical apps, etc.)

then we can make use of this hardware feature. I suspect this series tries to move 
in that direction.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/