> > > > Okay. We did a lot of discussion so it's better to summarise it. > > > > 1. ZONE_CMA might be a nicer solution than MIGRATETYPE. > > 2. Additional bit in page flags would cause another kind of > > maintenance problem so it's better to avoid it as much as possible. > > 3. Abusing ZONE_MOVABLE looks better than introducing ZONE_CMA since > > it doesn't need additional bit in page flag. > > 4. (Not-yet-finished) If ZONE_CMA doesn't need extra bit in page > > flags with hacky magic and it has no performance regression, > > ??? (it's okay to use separate zone for CMA?) > > As mentioned above. I do not see why we should go over additional hops > just to have a zone which is not strictly needed. So if there are no > inherent problems reusing MOVABLE/HIGMEM zone then a separate zone > sounds like a wrong direction. > > But let me repeat. I am _not_ convinced that the migratetype situation > is all that bad and unfixable. You have mentioned some issues with the > current approach but none of them seem inherently unfixable. So I would > still prefer keeping the current way. But I am not going to insist if > you _really_ believe that the long term maintenance cost will be higher > than a zone approach and you can reuse MOVABLE/HIGHMEM zones without > disruptive changes. I can help you with the hotplug part of the MOVABLE > zone because that is desirable on its own. Okay. Thanks for sharing your opinion. I will decide the final direction after some investigation. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
