On 06/11/2015 11:35 PM, Debabrata Banerjee wrote:
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.
Well that of course depends on the CPU utilization of "your process".
Your patch should help in that not every atomic allocation failure
should mean yet another run at compaction/reclaim.
If you don't want to wake up kswapd, add also __GFP_NO_KSWAPD flag.
Additionally, gfp_to_alloc_flags() will stop treating such allocation as
atomic - it allows atomic allocations to bypass cpusets and lowers the
watermark by 1/4 (unless there's also __GFP_NOMEMALLOC). It might
actually make sense to add __GFP_NO_KSWAPD for an allocation like this
one that has a simple order-0 fallback.
Vlastimil
-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>
--
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>