Andrew Morton wrote:

Nick Piggin [off-list ref] wrote:

quoted

Can you send the test app over?

logical next step.

quoted

Andrew, do you have any ideas about how to fix this so far?

Not sure what, if anything, is wrong yet.  It could be that reclaim is now
doing the "right" thing, but this particular workload preferred the "wrong"
thing.  Needs more investigation.

quoted

quoted

See how "cache" remains stable, but free/buffers memory is oscillating?
That shouldn't happen, right ? 

If it is doing IO to large regions of mapped memory, the page reclaim
can start getting a bit chunky. Not much you can do about it, but it
shouldn't do any harm.

shrink_zone() will free arbitrarily large amounts of memory as the scanning
priority increases.  Probably it shouldn't.

Especially for kswapd, I think, because it can end up fighting with
memory allocators and think it is getting into trouble. It should
probably rather just keep putting along quietly.

I have a few experimental patches that magnify this problem, so I'll
be looking at fixing it soon. The tricky part will be trying to
maintain a similar prev_priority / temp_priority balance.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>