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

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

On Tue, May 17, 2011 at 2:52 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Mon, May 16, 2011 at 07:40:42AM +0900, Minchan Kim wrote:
>> 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.
>
> I see.
>
>> >
>> > 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 :)
>
>> >
>> > - 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>