Messages in this thread | | | Date | Thu, 18 Jun 2015 11:55:42 +0200 | From | Vlastimil Babka <> | Subject | Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations |
| |
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 >
| |