So this thing has to be allocated from somewhere. We can't put iton the stack as we're already in danger there so we must be usingkmalloc. In the reclaim paths, this should be avoided obviously.For compaction, we might hurt the compaction success rates if pagesare pinned with control structures. It's something to be wary of.

At LSF/MM, I stated a preference for swapping the source anddestination pages in the LRU. This unfortunately means that the LRUnow contains a page in the process of being migrated to and the backoutpaths for migration failure become a lot more complex. Reclaim shouldbe ok as it'll should fail to lock the page and recycle it in the list.This avoids allocations but I freely admit that I'm not in the positionto implement such a thing right now :(

I think we also need counters at least at discussion stage to seehow successful this is.

For example, early in the system there is a casual relationshipbetween the age of a page and its location in physical memory. Thebuddy allocator gives pages back in PFN order where possible andthere is a loose relationship between when pages get allocated andwhen they get reclaimed. As compaction is a linear scanner, thereis a likelihood (that is highly variable) that physically contiguouspages will have similar positions in the LRU. They'll be isolated atthe same time meaning they also won't be put back in order.

This might cease to matter when the system is running for some time butit's a concern.