lkml.org 
[lkml]   [2010]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: OOM-Killer kills too much with 2.6.32.2
From
>> This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
>> GEM can't handle nor recover it. I suspect following commit is wrong.
>
> Indeed, the NORETRY flag is required for the inode mapping routines to
> return ENOMEM instead of triggering the OOM killer themselves. GEM has
> code to handle the ENOMEM as returned from shmem (please at least read the
> code before commenting, and comments are appreciated), by attempting to
> free up some of its own inactive buffers before retrying the allocation
> (with NORETRY removed, so the OOM killer will be invoked on the second
> instance). The reason for this convoluted approach is that GEM's inactive
> list shrinker requires the struct mutex and so cannot be run when GEM
> itself is attempting and failing to allocate memory. We could recover from
> more situations if we made some more invasive changes to our locking.
>
> This is without a doubt an area that needs improvement.

Please consider to revert such commit at once. Lots people reported
the same issue.
I really hope to stop bug report storm.


\
 
 \ /
  Last update: 2010-01-26 14:05    [W:0.490 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site