On 2015/06/16 2:20, Luck, Tony wrote:
On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote:
So, there are 3 ideas.
(1) kernel only from MIRROR / user only from MOVABLE (Tony)
(2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP) (AKPM
suggested)
This makes use of the fact MOVABLE memory is reclaimable but Tony pointed
out
the memory reclaim can be critical for GFP_ATOMIC.
(3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR
(Xishi)
2 Implementation ideas.
- creating ZONE
- creating new alloation attribute
I don't convince whether we need some new structure in mm. Isn't it good to use
ZONE_MOVABLE for not-mirrored memory ?
Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3)
We might need to rename it ... right now the memory hotplug
people use ZONE_MOVABLE to indicate regions of physical memory
that can be removed from the system. I'm wondering whether
people will want systems that have both removable and mirrored
areas? Then we have four attribute combinations:
mirror=no removable=no - prefer to use for user, could use for kernel if we
run out of mirror
mirror=no removable=yes - can only be used for user (kernel allocation makes
it not-removable)
mirror=yes removable=no - use for kernel, possibly for special users if we
define some interface
mirror=yes removable=yes - must not use for kernel ... would have to give to
user ... seems like a bad idea to configure a system this way
Thank you for clarification. I see "mirror=no, removable=no" case may require a
new name.
IMHO, the value of Address-Based-Memory-Mirror is that users can protect their
system's
important functions without using full-memory mirror. So, I feel thinking
"mirror=no, removable=no" just makes our discussion/implemenation complex
without real
user value.
Shouldn't we start with just thiking 2 cases of
mirror=no removable=yes
mirror=yes removable=no
?
And then, if the naming is problem, alias name can be added.
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
