On 06/11/2015 05:22 PM, Eric Dumazet wrote: > On Thu, 2015-06-11 at 17:16 -0400, Chris Mason wrote: >> On 06/11/2015 04:48 PM, Eric Dumazet 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. > > Exactly my point. (And I mentioned this about 4 months ago) Sorry, reading this again I wasn't very clear. I agree with Shaohua's patch because it is telling the allocator that we don't want to wait for reclaim or compaction to find contiguous pages. But, is there any fallback to a single page allocation somewhere else? If this is the only way to get memory, we might want to add a single alloc_page path that won't trigger compaction but is at least able to wait for kswapd to make progress. -chris -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
