Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations
From: Vlastimil Babka
Date: Thu Jun 18 2015 - 05:56:05 EST
On 06/18/2015 11:37 AM, Xishi Qiu wrote:
On 2015/6/18 13:58, Vlastimil Babka wrote:
On 18.6.2015 3:23, Xishi Qiu wrote:
On 2015/6/16 17:46, Vlastimil Babka wrote:
On the other hand, it would skip just as inefficiently over MIGRATE_MIRROR
pageblocks within a Normal zone. Since migrating pages between MIGRATE_MIRROR
and other types pageblocks would violate what the allocations requested.
Having separate zone instead would allow compaction to run specifically on the
zone and defragment movable allocations there (i.e. userspace pages if/when
userspace requesting mirrored memory is supported).
Hi Vlastimil,
If there are many mirror regions in one node, then it will be many holes in the
normal zone, is this fine?
Yeah, it doesn't matter how many holes there are.
So mirror zone and normal zone will span each other, right?
e.g. node 1: 4G-8G(normal), 8-12G(mirror), 12-16G(normal), 16-24G(mirror), 24-28G(normal) ...
normal: start=4G, size=28-4=24G,
mirror: start=8G, size=24-8=16G,
Yes, that works. It's somewhat unfortunate wrt performance that the
hardware does it like this though.
I think zone is defined according to the special address range, like 16M(DMA), 4G(DMA32),
Traditionally yes. But then there is ZONE_MOVABLE, this year's LSF/MM we
discussed (and didn't outright deny) ZONE_CMA...
I'm not saying others will favour the new zone approach though, it's
just my opinion that it might be a better option than a new migratetype.
and is it appropriate to add a new mirror zone with a volatile physical address?
By "volatile" you mean what, that the example above would change
dynamically? That would be rather challenging...
Thanks,
Xishi Qiu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/