On Fri, Jan 3, 2014 at 5:54 PM, Eric Dumazet [off-list ref] wrote:

This is in GFP_ATOMIC cases, I dont think it can ever start compaction.

I think that's right I probably finally got it back to normal behavior
with order-0 allocations.

It seems that you shoot the messenger : If memory is fragmented, then
one order-1 allocation is going to start compaction.

It can be a simple fork().

If your workload never fork(), then yes, you never needed compaction.

Sure but the rate of network packets in and out and subsequent
allocations would be more equivalent to a fork bomb than normal
forking. I understand mm should work more sanely in this scenario but
at the same time we see a bad regression with this code, I see we're
not alone.

We are not trying to optimize the kernel behavior for hosts in deep
memory pressure.

We're leaving about half for the kernel so I wouldn't call it "deep".
Any server application that is using page cache and mlocked memory
will run into similar issues.

It doesn't really matter to say that which memory allocation triggered
compaction, which is a normal step in mm layer.

If you believe its badly done, you should ask to mm guys to fix/improve
it, not netdev...

Using order-3 pages in TCP stack improves performance for 99% of the
hosts, there might be something wrong on your side ?

Having lots of memory mlocked is bad right now yes, but not
necessarily an uncommon scenario. We're handing mm an almost
intractable problem. I see compaction of mlocked pages has been
discussed a few times over there, but no patch has actually made it
in.

-Debabrata