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

[Minchan Kim <minchan.kim@gmail.com>]

On Mon, May 16, 2011 at 12:27 AM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Sun, May 15, 2011 at 09:37:58AM +0800, Minchan Kim wrote:
>> On Sun, May 15, 2011 at 2:43 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> > Copying back linux-mm.
>> >
>> >> 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.

>
> 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. :)

>
> - 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.
My patch and shrinking RA window helps this case.

-- 
Kind regards,
Minchan Kim