From: Xishi Qiu <qiuxishi@huawei.com>
To: David Rientjes <rientjes@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
arve@android.com, riandrews@android.com,
devel@driverdev.osuosl.org, zhong jiang <zhongjiang@huawei.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan()
Date: Wed, 17 Feb 2016 16:30:19 +0800 [thread overview]
Message-ID: <56C42F9B.2050309@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1602161629560.19997@chino.kir.corp.google.com>
On 2016/2/17 8:35, David Rientjes wrote:
> On Tue, 16 Feb 2016, Greg Kroah-Hartman wrote:
>
>> On Tue, Feb 16, 2016 at 05:37:05PM +0800, Xishi Qiu wrote:
>>> Currently tasksize in lowmem_scan() only calculate rss, and not include swap.
>>> But usually smart phones enable zram, so swap space actually use ram.
>>
>> Yes, but does that matter for this type of calculation? I need an ack
>> from the android team before I could ever take such a core change to
>> this code...
>>
>
> The calculation proposed in this patch is the same as the generic oom
> killer, it's an estimate of the amount of memory that will be freed if it
> is killed and can exit. This is better than simply get_mm_rss().
>
> However, I think we seriously need to re-consider the implementation of
> the lowmem killer entirely. It currently abuses the use of TIF_MEMDIE,
> which should ideally only be set for one thread on the system since it
> allows unbounded access to global memory reserves.
>
> It also abuses the user-visible /proc/self/oom_score_adj tunable: this
> tunable is used by the generic oom killer to bias or discount a proportion
> of memory from a process's usage. This is the only supported semantic of
> the tunable. The lowmem killer uses it as a strict prioritization, so any
> process with oom_score_adj higher than another process is preferred for
> kill, REGARDLESS of memory usage. This leads to priority inversion, the
> user is unable to always define the same process to be killed by the
> generic oom killer and the lowmem killer. This is what happens when a
> tunable with a very clear and defined purpose is used for other reasons.
>
> I'd seriously consider not accepting any additional hacks on top of this
> code until the implementation is rewritten.
>
Hi David,
Thanks for your advice.
I have a stupid question, what's the main difference between lmk and oom?
1) lmk is called when reclaim memory, and oom is called when alloc failed in slow path.
2) lmk has several lowmem thresholds and oom is not.
3) others?
Thanks,
Xishi Qiu
> .
>
--
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:[~2016-02-17 8:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 9:37 Xishi Qiu
2016-02-16 17:38 ` Greg Kroah-Hartman
2016-02-17 0:35 ` David Rientjes
2016-02-17 8:30 ` Xishi Qiu [this message]
2016-02-17 22:42 ` David Rientjes
2016-02-17 18:10 ` Michal Hocko
2016-02-18 6:51 ` Xishi Qiu
2016-02-23 0:54 ` David Rientjes
2016-02-18 7:55 ` Figo.zhang
2016-02-18 10:21 ` Xishi Qiu
2016-02-23 0:50 ` David Rientjes
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=56C42F9B.2050309@huawei.com \
--to=qiuxishi@huawei.com \
--cc=arve@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riandrews@android.com \
--cc=rientjes@google.com \
--cc=zhongjiang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox