Messages in this thread | | | Date | Mon, 11 May 2009 16:40:08 +0900 | From | Minchan Kim <> | Subject | Re: [patch 08/11 -mmotm] oom: invoke oom killer for __GFP_NOFAIL |
| |
On Mon, 11 May 2009 10:45:05 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > On Mon, 11 May 2009, KOSAKI Motohiro wrote: > > > > > > The oom killer must be invoked regardless of the order if the allocation > > > > is __GFP_NOFAIL, otherwise it will loop forever when reclaim fails to > > > > free some memory. > > > > > > This is intensional behavior. plus you change very widely caller bahavior. > > > if you don't have good test program, I nak this. > > > > > > > What exactly are you objecting to? You don't want the oom killer called > > for a __GFP_NOFAIL allocation above PAGE_ALLOC_COSTLY_ORDER that could not > > reclaim any memory and would prefer that it loop endlessly in the page > > allocator? What's the purpose of that if the oom killer could free a very > > large memory hogging task? > > My point is, if we change gfp-flags meaning, we should change > unintentional affected caller. > > Do you oppose this? >
I agree KOSAKI's opinion. We already have a different flags.
* __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt * _might_ fail. This depends upon the particular VM implementation. * * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures.
When we use __GFP_NOFAIL, we always have to use it carefully. If you change the meaning of __GFP_NOFAIL, the intension of them who have been used it carefully may be lost. It's my concern.
-- Kinds Regards Minchan Kim
| |