All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Dave Peterson <dsp@llnl.gov>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, pj@sgi.com,
	ak@suse.de, linux-mm@kvack.org, garlick@llnl.gov,
	mgrondona@llnl.gov
Subject: Re: [PATCH (try #3)] mm: avoid unnecessary OOM kills
Date: Mon, 29 May 2006 16:12:42 +1000	[thread overview]
Message-ID: <447A90DA.3020502@yahoo.com.au> (raw)
In-Reply-To: <7.0.0.16.2.20060524073251.0237c250@llnl.gov>

Dave Peterson wrote:
> At 04:43 PM 5/23/2006, Nick Piggin wrote:

>>>I agree it's desirable to keep the OOM killing logic as encapsulated
>>>as possible.  However unless you are holding the oom kill semaphore
>>>when you make your final attempt to allocate memory it's a bit racy.
>>>Holding the OOM kill semaphore guarantees that our final allocation
>>>failure before invoking the OOM killer occurred _after_ any previous
>>>OOM kill victim freed its memory.  Thus we know we are not shooting
>>>another process prematurely (i.e. before the memory-freeing effects
>>>of our previous OOM kill have been felt).
>>
>>But there is so much fudge in it that I don't think it matters:
>>pages could be freed from other sources, some reclaim might happen,
>>the point at which OOM is declared is pretty arbitrary anyway, etc.
> 
> 
> There's definitely some fudge in it.  However the main scenario I'm
> concerned with is where one big process is hogging most of the memory
> (as opposed to a case where the collective memory-hogging effect of
> lots of little processes triggers the OOM killer).  In the first case
> we want to shoot the one big process and leave the little processes
> undisturbed.
> 
> If the final allocation failure before invoking the OOM killer
> occurs when we don't yet hold the OOM kill semaphore then I'd
> be concerned about processes queueing up on the OOM kill semaphore
> after they fail their memory allocations.  If only one of these
> ends up getting awakened _after_ the death of the big memory hog,
> then that process will enter the OOM killer and shoot a little
> process unnecessarily.
> 
> Alternately (perhaps less likely), if your kernel is preemptible,
> after the memory hog has been shot but not yet expired a process
> may get preempted between its final allocation failure and its
> choosing an OOM kill victim (with the memory hog expiring before
> the preempted process gets rescheduled).  Then the preempted
> process shoots a little process when rescheduled.

But just call into the oom killer, and let it queue up and/or do
nothing according to whether there is still a task being shot or
not.

page allocation would then just try again.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Dave Peterson <dsp@llnl.gov>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, pj@sgi.com,
	ak@suse.de, linux-mm@kvack.org, garlick@llnl.gov,
	mgrondona@llnl.gov
Subject: Re: [PATCH (try #3)] mm: avoid unnecessary OOM kills
Date: Mon, 29 May 2006 16:12:42 +1000	[thread overview]
Message-ID: <447A90DA.3020502@yahoo.com.au> (raw)
In-Reply-To: <7.0.0.16.2.20060524073251.0237c250@llnl.gov>

Dave Peterson wrote:
> At 04:43 PM 5/23/2006, Nick Piggin wrote:

>>>I agree it's desirable to keep the OOM killing logic as encapsulated
>>>as possible.  However unless you are holding the oom kill semaphore
>>>when you make your final attempt to allocate memory it's a bit racy.
>>>Holding the OOM kill semaphore guarantees that our final allocation
>>>failure before invoking the OOM killer occurred _after_ any previous
>>>OOM kill victim freed its memory.  Thus we know we are not shooting
>>>another process prematurely (i.e. before the memory-freeing effects
>>>of our previous OOM kill have been felt).
>>
>>But there is so much fudge in it that I don't think it matters:
>>pages could be freed from other sources, some reclaim might happen,
>>the point at which OOM is declared is pretty arbitrary anyway, etc.
> 
> 
> There's definitely some fudge in it.  However the main scenario I'm
> concerned with is where one big process is hogging most of the memory
> (as opposed to a case where the collective memory-hogging effect of
> lots of little processes triggers the OOM killer).  In the first case
> we want to shoot the one big process and leave the little processes
> undisturbed.
> 
> If the final allocation failure before invoking the OOM killer
> occurs when we don't yet hold the OOM kill semaphore then I'd
> be concerned about processes queueing up on the OOM kill semaphore
> after they fail their memory allocations.  If only one of these
> ends up getting awakened _after_ the death of the big memory hog,
> then that process will enter the OOM killer and shoot a little
> process unnecessarily.
> 
> Alternately (perhaps less likely), if your kernel is preemptible,
> after the memory hog has been shot but not yet expired a process
> may get preempted between its final allocation failure and its
> choosing an OOM kill victim (with the memory hog expiring before
> the preempted process gets rescheduled).  Then the preempted
> process shoots a little process when rescheduled.

But just call into the oom killer, and let it queue up and/or do
nothing according to whether there is still a task being shot or
not.

page allocation would then just try again.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-05-29  6:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-23  0:32 [PATCH (try #3)] mm: avoid unnecessary OOM kills Dave Peterson
2006-05-23  0:32 ` Dave Peterson
2006-05-23  5:39 ` Nick Piggin
2006-05-23  5:39   ` Nick Piggin
2006-05-23 18:04   ` Dave Peterson
2006-05-23 18:04     ` Dave Peterson
2006-05-23 23:43     ` Nick Piggin
2006-05-23 23:43       ` Nick Piggin
2006-05-24 15:05       ` Dave Peterson
2006-05-24 15:05         ` Dave Peterson
2006-05-29  6:12         ` Nick Piggin [this message]
2006-05-29  6:12           ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=447A90DA.3020502@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=dsp@llnl.gov \
    --cc=garlick@llnl.gov \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgrondona@llnl.gov \
    --cc=pj@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.