Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux)

On Tue, May 17, 2011 at 2:52 PM, Wu Fengguang [off-list ref] wrote:

On Mon, May 16, 2011 at 07:40:42AM +0900, Minchan Kim wrote:

quoted

On Mon, May 16, 2011 at 12:27 AM, Wu Fengguang [off-list ref] wrote:

quoted

On Sun, May 15, 2011 at 09:37:58AM +0800, Minchan Kim wrote:

quoted

On Sun, May 15, 2011 at 2:43 AM, Andi Kleen [off-list ref] wrote:

quoted

Copying back linux-mm.

quoted

Recently, we added following patch.
https://lkml.org/lkml/2011/4/26/129
If it's a culprit, the patch should solve the problem.

It would be probably better to not do the allocations at all under
memory pressure.  Even if the RA allocation doesn't go into reclaim

Fair enough.
I think we can do it easily now.
If page_cache_alloc_readahead(ie, GFP_NORETRY) is fail, we can adjust
RA window size or turn off a while. The point is that we can use the
fail of __do_page_cache_readahead as sign of memory pressure.
Wu, What do you think?

No, disabling readahead can hardly help.

I don't mean we have to disable RA.
As I said, the point is that we can use __GFP_NORETRY alloc fail as
_sign_ of memory pressure.

I see.

quoted

quoted

The sequential readahead memory consumption can be estimated by

               2 * (number of concurrent read streams) * (readahead window size)

And you can double that when there are two level of readaheads.

Since there are hardly any concurrent read streams in Andy's case,
the readahead memory consumption will be ignorable.

Typically readahead thrashing will happen long before excessive
GFP_NORETRY failures, so the reasonable solutions are to

If it is, RA thrashing could be better sign than failure of __GFP_NORETRY.
If we can do it easily, I don't object it. :)

Yeah, the RA thrashing is much better sign because it not only happens
long before normal __GFP_NORETRY failures, but also offers hint on how
tight memory pressure it is. We can then shrink the readahead window
adaptively to the available page cache memory :)

quoted

quoted

- shrink readahead window on readahead thrashing
 (current readahead heuristic can somehow do this, and I have patches
 to further improve it)

Good to hear. :)
I don't want RA steals high order page in memory pressure.

More often than not it won't be RA's fault :)  When you see RA page
allocations stealing high order pages, it may actually be reflecting
some more general order-0 steal order-N problem..

Agree.
As I said to Andy, it's a general problem but RA has a possibility to
reduce it while others don't have a any solution. :(

-- 
Kind regards,
Minchan Kim

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>