Re: [PATCH (try #2)] mm: avoid unnecessary OOM kills

[Dave Peterson <dsp@llnl.gov>]

At 03:12 PM 5/22/2006, Paul Jackson wrote:
>Why disable this printk_ratelimit?  Does this expose us to a Denial of
>Service attack from someone forcing multiple oom-kills in a small
>cpuset, generating much kernel printk output?

I figured that the printk_ratelimit() was probably placed there to
eliminate excessive noise due to the following scenario:

    - Process X calls out_of_memory() and shoots process Y.
    - Until Y gets a chance to execute and expire, lots of
      other processes will probably be failing their memory
      allocations and calling out_of_memory(), spewing more
      printk() messages.

I figured that since serializing the OOM kills would eliminate
this behavior, the printk_ratelimit() was no longer necessary.

However, there would still be lots of messages if the OOM killer
is repeatedly triggered due to lots of little processes eating
up memory.  In this case the printk_ratelimit() would serve a
purpose.  In any event there's no harm in leaving it in.  I'll
add back the printk_ratelimit() and make a new patch...

>> +/* Try to allocate one more time before invoking the OOM killer. */
>> +static struct page * oom_alloc(gfp_t gfp_mask, unsigned int order,
>
>This comment is slightly stale.  Not only does oom_alloc() try one
>more allocation, it also actually does invoke the OOM killer.
>
>How about the comment:
>
>   /* Serialize oom killing, while trying to allocate a page */
>
>Or some such ..

How about the following?

/* If an OOM kill is not already in progress, try once more to
 * allocate memory.  If allocation fails this time, invoke the
 * OOM killer.
 */



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/