lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [patch -mmotm] mm: invoke oom killer for __GFP_NOFAIL
From
On Tue, May 12, 2009 at 6:32 AM, Mel Gorman <mel@csn.ul.ie> wrote:
> On Mon, May 11, 2009 at 11:00:44PM +0900, Minchan Kim wrote:
>> Hi, Mel.
>>
>> On Mon, May 11, 2009 at 10:38 PM, Mel Gorman <mel@csn.ul.ie> wrote:
>> > On Mon, May 11, 2009 at 08:21:21PM +0900, Minchan Kim wrote:
>> >> On Mon, May 11, 2009 at 6:12 PM, Minchan Kim <minchan.kim@gmail.com> wrote:
>> >> > On Mon, May 11, 2009 at 5:40 PM, David Rientjes <rientjes@google.com> wrote:
>> >> >> On Mon, 11 May 2009, Minchan Kim wrote:
>> >> >>
>> >> >>> Hmm.. if __alloc_pages_may_oom fail to allocate free page due to order > PAGE_ALLOC_COSTRY_ORDER,
>> >> >>>
>> >> >>> It will go to nopage label in __alloc_pages_slowpath.
>> >> >>> Then it will show the page allocation failure warning and will return.
>> >> >>> Retrying depends on caller.
>> >> >>>
>> >> >>
>> >> >> Correct.
>> >> >>
>> >> >>> So, I think it won't loop forever.
>> >> >>> Do I miss something ?
>> >> >>>
>> >> >>
>> >> >> __GFP_NOFAIL allocations shouldn't fail, that's the point of the gfp flag.
>> >> >> So failing without attempting to free some memory is the wrong thing to
>> >> >> do.
>> >> >
>> >> > Thanks for quick reply.
>> >> > I was confused by your description.
>> >> > I thought you suggested we have to prevent loop forever.
>> >> >
>> >> >>
>> >> >>> In addition, the OOM killer can help for getting the high order pages ?
>> >> >>>
>> >> >>
>> >> >> Sure, if it selects a task that will free a lot of memory, which is it's
>> >> >> goal.
>> >> >>
>> >> >
>> >> > How do we know any task have a lot of memory ?
>> >> > If we select wrong task and kill one ?
>> >> >
>> >> > I have a concern about innocent task.
>> >>
>> >> Now, I look over __out_of_memory.
>> >> For selecting better tasks in case of PAGE_ALLOC_COSTRY_ORDER, How
>> >> about increasing score of task which have VM_HUGETLB vma in badness ?
>> >>
>> >
>> > That is unjustified. It penalises a process even if it only allocated one
>> > hugepage and it is not a reflection of how much memory the process is using
>> > or how badly behaved it is.
>> > Even worse, if the huge page was allocated from the static hugepage pool then
>> > the hugepages are freed to the hugepage pool and not the page allocator when
>> > the process is killed. This means that killing a process using hugepages
>> > does not necessarily help applications requiring more memory unless they
>> > also want hugepages. However, a hugepage allocation will not trigger the
>> > OOM killer so killing processes using hugepages still does not help.
>>
>> Thanks for pointing me.
>> In fact, I expect your great answer. :)
>>
>> So, how do we prevent innocent task killing for allocation of high order page ?
>
> Not by targetting users of hugepages anyway, that's for sure. My expectation
> normally for a high-order allocation failing is for the caller to recover
> from the situation gracefully. In the event it can't, the caller is running
> a major risk and I would question why it's __GFP_NOFAIL.

I agree.

> I recognise that this is not much of an answer. I haven't read all the
> related threads so I don't know what application is depending so heavily on
> high-order allocations succeeding that it warrented __GFP_NOFAIL and couldn't
> be addressed in some other fashion like vmalloc().
>
> Killing a process allocating huges will only help another process requiring
> hugepages. Unless dynamic hugepage pool resizing was used, the pages freed
> are not usable for normal high-order allocations so teaching the OOM
> killer to target those processes is unlikely to help solve whatever
> problem is being addressed.
>
>> I think it is trade off. but at least, we have been prevent it until now.
>>
>> But this patch increases the probability of innocent task killing.
>
> I think any increase in probability is minimal. When it gets down to it, there
> should be zero costly-high-order allocations that are also __GFP_NOFAIL. If
> anything, the patch would show up as OOM-kill pointing out what caller needs to
> be fixed as opposed to having apparently infinite loops in the page allocator.

OK.

>> Is GFP_NOFAIL's early bailout more important than killing of innocent task ?
>>
>
> In my opinion, yes, in the sense that a OOM-kill report is easier to diagnose
> than an infinite loop.

Yes. I agree, too.

Thanks for great review, Mel. :)

--
Kinds regards,
Minchan Kim


\
 
 \ /
  Last update: 2009-05-12 01:45    [W:0.059 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site