There is no "background" it doesn't matter if this activity happens synchronously or asynchronously, unless you're sensitive to the latency on that single operation. If you're driving all your cpu's and memory hard then this is work that still takes resources. If there's a kernel thread with compaction running, then obviously your process is not. Your patch should help in that not every atomic allocation failure should mean yet another run at compaction/reclaim. -Deb On Thu, Jun 11, 2015 at 5:16 PM, Chris Mason <clm@xxxxxx> wrote: > networking is asking for 32KB, and the MM layer is doing what it can to > provide it. Are the gains from getting 32KB contig bigger than the cost > of moving pages around if the MM has to actually go into compaction? > Should we start disk IO to give back 32KB contig? > > I think we want to tell the MM to compact in the background and give > networking 32KB if it happens to have it available. If not, fall back > to smaller allocations without doing anything expensive. > -- 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>