From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Jeff Davis <linux@j-davis.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] badness() dramatically overcounts memory
Date: Tue, 05 Feb 2008 09:43:54 +0530 [thread overview]
Message-ID: <47A7E282.1080902@linux.vnet.ibm.com> (raw)
In-Reply-To: <1202182480.24634.22.camel@dogma.ljc.laika.com>
Jeff Davis wrote:
> In oom_kill.c, one of the badness calculations is wildly inaccurate. If
> memory is shared among child processes, that same memory will be counted
> for each child, effectively multiplying the memory penalty by N, where N
> is the number of children.
>
> This makes it almost certain that the parent will always be chosen as
> the victim of the OOM killer (assuming any substantial amount memory
> shared among the children), even if the parent and children are well
> behaved and have a reasonable and unchanging VM size.
>
> Usually this does not actually alleviate the memory pressure because the
> truly bad process is completely unrelated; and the OOM killer must later
> kill the truly bad process.
>
> This trivial patch corrects the calculation so that it does not count a
> child's shared memory against the parent.
>
Hi, Jeff,
1. grep on the kernel source tells me that shared_vm is incremented only in
vm_stat_account(), which is a NO-OP if CONFIG_PROC_FS is not defined.
2. How have you tested these patches? One way to do it would be to use the
memory controller and set a small limit on the control group. A memory
intensive application will soon see an OOM.
I do need to look at OOM kill sanity, my colleagues using the memory controller
have reported wrong actions taken by the OOM killer, but I am yet to analyze them.
The interesting thing is the use of total_vm and not the RSS which is used as
the basis by the OOM killer. I need to read/understand the code a bit more.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Jeff Davis <linux@j-davis.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] badness() dramatically overcounts memory
Date: Tue, 05 Feb 2008 09:43:54 +0530 [thread overview]
Message-ID: <47A7E282.1080902@linux.vnet.ibm.com> (raw)
In-Reply-To: <1202182480.24634.22.camel@dogma.ljc.laika.com>
Jeff Davis wrote:
> In oom_kill.c, one of the badness calculations is wildly inaccurate. If
> memory is shared among child processes, that same memory will be counted
> for each child, effectively multiplying the memory penalty by N, where N
> is the number of children.
>
> This makes it almost certain that the parent will always be chosen as
> the victim of the OOM killer (assuming any substantial amount memory
> shared among the children), even if the parent and children are well
> behaved and have a reasonable and unchanging VM size.
>
> Usually this does not actually alleviate the memory pressure because the
> truly bad process is completely unrelated; and the OOM killer must later
> kill the truly bad process.
>
> This trivial patch corrects the calculation so that it does not count a
> child's shared memory against the parent.
>
Hi, Jeff,
1. grep on the kernel source tells me that shared_vm is incremented only in
vm_stat_account(), which is a NO-OP if CONFIG_PROC_FS is not defined.
2. How have you tested these patches? One way to do it would be to use the
memory controller and set a small limit on the control group. A memory
intensive application will soon see an OOM.
I do need to look at OOM kill sanity, my colleagues using the memory controller
have reported wrong actions taken by the OOM killer, but I am yet to analyze them.
The interesting thing is the use of total_vm and not the RSS which is used as
the basis by the OOM killer. I need to read/understand the code a bit more.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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>
next prev parent reply other threads:[~2008-02-05 4:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 3:34 [PATCH] badness() dramatically overcounts memory Jeff Davis
2008-02-05 4:13 ` Balbir Singh [this message]
2008-02-05 4:13 ` Balbir Singh
2008-02-05 23:02 ` Jeff Davis
2008-02-05 23:02 ` Jeff Davis
2008-02-05 23:09 ` David Rientjes
2008-02-05 23:09 ` David Rientjes
2008-02-06 1:54 ` KOSAKI Motohiro
2008-02-06 1:54 ` KOSAKI Motohiro
2008-02-06 2:05 ` David Rientjes
2008-02-06 2:05 ` David Rientjes
2008-02-06 4:00 ` Balbir Singh
2008-02-06 4:00 ` Balbir Singh
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=47A7E282.1080902@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@j-davis.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.