From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: "Arve Hj�nnev虍" <arve@android.com>
Cc: kosaki.motohiro@jp.fujitsu.com, "Greg KH" <greg@kroah.com>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"Pavel Machek" <pavel@suse.cz>,
"Brian Swetland" <swetland@google.com>,
arve@google.com, "San Mehat" <san@android.com>,
"Robert Love" <rlove@google.com>,
linux-kernel@vger.kernel.org,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Tony Lindgren" <tony@atomide.com>,
"ext Juha Yrj�l・" <juha.yrjola@solidboot.com>,
viktor.rosendahl@nokia.com, "Trilok Soni" <soni.trilok@gmail.com>
Subject: Re: lowmemory android driver not needed?
Date: Thu, 29 Jan 2009 10:48:09 +0900 (JST) [thread overview]
Message-ID: <20090128234209.A949.KOSAKI.MOTOHIRO@jp.fujitsu.com> (raw)
In-Reply-To: <d6200be20901212213x1069762cpd377d04bc5a04a91@mail.gmail.com>
Hi
> On Fri, Jan 16, 2009 at 5:18 AM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
> > also quick review to lowmemorykiller.c
>
> >> static struct shrinker lowmem_shrinker = {
> >> .shrink = lowmem_shrink,
> >> .seeks = DEFAULT_SEEKS * 16
> >> };
> >
> > why do you choice *16?
>
> To indicate that it is more expensive to restart a killed process than
> a regular cache page.
I think you already know this answer isn't actual answer.
anybody know >1 mean expensive. a reviewer want to know why DEFAULT_SEEKS * 16
is best, not *10 nor *20.
> >> static uint32_t lowmem_debug_level = 2;
> >> static int lowmem_adj[6] = {
> >
> > why do you choice [6]?
>
> We use six levels.
if you don't consider other user and other usage case,
this file can't merge forever.
The top problem is, this file stay on non proper place.
then, MM folks don't review at all.
I think this patch need to receive MM folks review.
Greg, please drop this file from stagin awhile.
(of cource, my intention is this one file only, other hardware depended
driver file is needed to staging)
Naked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> >> static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
> >> {
> >> struct task_struct *p;
> >> struct task_struct *selected = NULL;
> >> int rem = 0;
> >> int tasksize;
> >> int i;
> >> int min_adj = OOM_ADJUST_MAX + 1;
> >> int selected_tasksize = 0;
> >> int array_size = ARRAY_SIZE(lowmem_adj);
> >> int other_free = global_page_state(NR_FREE_PAGES) + global_page_state(NR_FILE_PAGES);
> >
> > I think you don't consider mlocked page (and/or other unevictable page).
> > if much mlocked file page exist, other_free can become large value.
> > then, this routine don't kill any process.
>
> Yes, this is a problem we have seen, but I did not find counter for
> pinned cache pages. I may be able to use NR_UNEVICTABLE if
> CONFIG_UNEVICTABLE_LRU is enabled now though.
hm hom.
> Another problem we run into is that allocations of contiguous pages
> can cause kswapd to empty all the caches. This will not trigger this
> lowmemorykiller or the regular oom killer.
strange usage.
you shouldn't use high order allocation on embedded machine.
> >> read_lock(&tasklist_lock);
> >> for_each_process(p) {
> >
> > Oops. too long locking.
> > shrink_slab() is freqentlly called function. I don't like costly operation.
> >
> >> if(p->oomkilladj >= 0 && p->mm) {
> >> tasksize = get_mm_rss(p->mm);
> >> if(nr_to_scan > 0 && tasksize > 0 && p->oomkilladj >= min_adj) {
> >> if(selected == NULL ||
> >> p->oomkilladj > selected->oomkilladj ||
> >> (p->oomkilladj == selected->oomkilladj &&
> >> tasksize > selected_tasksize)) {
> >> selected = p;
> >> selected_tasksize = tasksize;
> >> lowmem_print(2, "select %d (%s), adj %d, size %d, to kill\n",
> >> p->pid, p->comm, p->oomkilladj, tasksize);
> >> }
> >> }
> >> rem += tasksize;
> >
> > this code mean,
> > shrinker->shrink(0, gfp_mask) indicate to recalculate total rss every time.
> > it is too CPU and battery wasting.
> >
>
> How about this:
> ----
> diff --git a/drivers/misc/lowmemorykiller.c b/drivers/misc/lowmemorykiller.c
> index 3715d56..3f4e41a 100644
> --- a/drivers/misc/lowmemorykiller.c
> +++ b/drivers/misc/lowmemorykiller.c
> @@ -71,6 +71,12 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
> }
> if(nr_to_scan > 0)
> lowmem_print(3, "lowmem_shrink %d, %x, ofree %d, ma
> %d\n", nr_to_scan, gfp_mask, other_free, min_adj);
> + rem = global_page_state(NR_ACTIVE_ANON) +
> global_page_state(NR_ACTIVE_FILE);
> + if (!nr_to_scan || min_adj == OOM_ADJUST_MAX + 1) {
> + lowmem_print(5, "lowmem_shrink %d, %x, return %d\n",
> nr_to_scan, gfp_mask, rem);
> + return rem;
> + }
> +
I don't understand your intention.
if file server machine has tons NR_ACTIVE_FILE, this logic kill many
process.
Do I misunderstand anything?
> read_lock(&tasklist_lock);
> for_each_process(p) {
> if(p->oomkilladj >= 0 && p->mm) {
> @@ -86,7 +92,6 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
> p->pid, p->comm,
> p->oomkilladj, tasksize);
> }
> }
> - rem += tasksize;
> }
> }
> if(selected != NULL) {
next prev parent reply other threads:[~2009-01-29 1:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-14 1:02 Greg KH
2009-01-14 2:18 ` Brian Swetland
2009-01-14 2:30 ` Arve Hjønnevåg
2009-01-14 3:52 ` Greg KH
2009-01-14 10:43 ` Pavel Machek
2009-01-14 10:48 ` Alan Cox
2009-01-14 12:18 ` MinChan Kim
2009-01-14 22:26 ` Arve Hjønnevåg
2009-01-14 23:17 ` Greg KH
2009-01-14 23:32 ` Arve Hjønnevåg
2009-01-15 0:12 ` Greg KH
2009-01-15 0:54 ` [PATCH] Staging: android: Add lowmemorykiller documentation Arve Hjønnevåg
2009-01-15 0:59 ` Greg KH
2009-01-15 13:32 ` lowmemory android driver not needed? Trilok Soni
2009-01-15 23:44 ` Greg KH
2009-01-16 9:02 ` Paul Mundt
2009-01-16 11:16 ` KOSAKI Motohiro
2009-01-16 15:23 ` Greg KH
2009-01-21 2:50 ` KOSAKI Motohiro
2009-01-21 3:05 ` Paul Mundt
2009-01-21 3:29 ` KAMEZAWA Hiroyuki
2009-04-01 18:38 ` Trilok Soni
2009-04-01 19:33 ` David Rientjes
2009-02-03 20:55 ` Tony Lindgren
2009-01-16 11:42 ` KOSAKI Motohiro
2009-01-16 13:18 ` KOSAKI Motohiro
2009-01-22 6:13 ` Arve Hjønnevåg
2009-01-29 1:48 ` KOSAKI Motohiro [this message]
2009-01-29 2:51 ` Arve Hjønnevåg
2009-01-29 3:45 ` KAMEZAWA Hiroyuki
2009-01-29 4:27 ` Greg KH
2009-01-29 4:43 ` KOSAKI Motohiro
2009-01-29 4:59 ` Greg KH
2009-01-29 5:29 ` KOSAKI Motohiro
2009-01-30 6:20 ` Greg KH
2009-01-30 6:41 ` Brian Swetland
2009-02-03 13:40 ` KOSAKI Motohiro
2009-01-29 22:06 ` Pavel Machek
2009-02-03 14:08 ` KOSAKI Motohiro
2009-01-15 7:55 ` David Rientjes
2009-01-14 6:45 ` MinChan Kim
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=20090128234209.A949.KOSAKI.MOTOHIRO@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arve@android.com \
--cc=arve@google.com \
--cc=greg@kroah.com \
--cc=juha.yrjola@solidboot.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=rlove@google.com \
--cc=san@android.com \
--cc=soni.trilok@gmail.com \
--cc=swetland@google.com \
--cc=tony@atomide.com \
--cc=viktor.rosendahl@nokia.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
all inboxes | Powered by JetHome®