From: Xishi Qiu <qiuxishi@huawei.com>
To: "Figo.zhang" <figo1802@gmail.com>, 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: Thu, 18 Feb 2016 18:21:45 +0800 [thread overview]
Message-ID: <56C59B39.30102@huawei.com> (raw)
In-Reply-To: <CAF7GXvqr2dmc7CUcs_OmfYnEA9jE_Db4kGGG1HJyYYLhC6Bgew@mail.gmail.com>
On 2016/2/18 15:55, Figo.zhang wrote:
>
>
> 2016-02-17 8:35 GMT+08:00 David Rientjes <rientjes@google.com <mailto:rientjes@google.com>>:
>
> 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.
>
>
>
> i don't understand why it need wait 1 second:
>
Hi David,
How about kill more processes at one time?
Usually loading camera will alloc 300-500M memory immediately, so call lmk
repeatedly is a waste of time.
And can we reclaim memory at one time instead of reclaim-alloc-reclaim-alloc...
in this situation? e.g. use try_to_free_pages(), set nr_to_reclaim=300M
Thanks,
Xishi Qiu
> if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
> time_before_eq(jiffies, lowmem_deathpending_timeout)) {
> task_unlock(p);
> rcu_read_unlock();
> return 0; <= why return rather than continue?
> }
>
> and it will retry and wait many CPU times if one task holding the TIF_MEMDI.
> shrink_slab_node()
> while()
> shrinker->scan_objects();
> lowmem_scan()
> if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
> time_before_eq(jiffies, lowmem_deathpending_timeout))
>
>
>
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: "Figo.zhang" <figo1802@gmail.com>, 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: Thu, 18 Feb 2016 18:21:45 +0800 [thread overview]
Message-ID: <56C59B39.30102@huawei.com> (raw)
In-Reply-To: <CAF7GXvqr2dmc7CUcs_OmfYnEA9jE_Db4kGGG1HJyYYLhC6Bgew@mail.gmail.com>
On 2016/2/18 15:55, Figo.zhang wrote:
>
>
> 2016-02-17 8:35 GMT+08:00 David Rientjes <rientjes@google.com <mailto:rientjes@google.com>>:
>
> 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.
>
>
>
> i don't understand why it need wait 1 second:
>
Hi David,
How about kill more processes at one time?
Usually loading camera will alloc 300-500M memory immediately, so call lmk
repeatedly is a waste of time.
And can we reclaim memory at one time instead of reclaim-alloc-reclaim-alloc...
in this situation? e.g. use try_to_free_pages(), set nr_to_reclaim=300M
Thanks,
Xishi Qiu
> if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
> time_before_eq(jiffies, lowmem_deathpending_timeout)) {
> task_unlock(p);
> rcu_read_unlock();
> return 0; <= why return rather than continue?
> }
>
> and it will retry and wait many CPU times if one task holding the TIF_MEMDI.
> shrink_slab_node()
> while()
> shrinker->scan_objects();
> lowmem_scan()
> if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
> time_before_eq(jiffies, lowmem_deathpending_timeout))
>
>
>
>
next prev parent reply other threads:[~2016-02-18 10:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 9:37 [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan() Xishi Qiu
2016-02-16 9:37 ` Xishi Qiu
2016-02-16 17:38 ` Greg Kroah-Hartman
2016-02-16 17:38 ` Greg Kroah-Hartman
2016-02-17 0:35 ` David Rientjes
2016-02-17 0:35 ` David Rientjes
2016-02-17 8:30 ` Xishi Qiu
2016-02-17 8:30 ` Xishi Qiu
2016-02-17 22:42 ` David Rientjes
2016-02-17 22:42 ` David Rientjes
2016-02-17 18:10 ` Michal Hocko
2016-02-17 18:10 ` Michal Hocko
2016-02-18 6:51 ` Xishi Qiu
2016-02-18 6:51 ` Xishi Qiu
2016-02-23 0:54 ` David Rientjes
2016-02-23 0:54 ` David Rientjes
2016-02-18 7:55 ` Figo.zhang
2016-02-18 10:21 ` Xishi Qiu [this message]
2016-02-18 10:21 ` Xishi Qiu
2016-02-23 0:50 ` David Rientjes
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=56C59B39.30102@huawei.com \
--to=qiuxishi@huawei.com \
--cc=arve@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=figo1802@gmail.com \
--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 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.