[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090306191436.ceeb6e42.kamezawa.hiroyu@jp.fujitsu.com>
Date: Fri, 6 Mar 2009 19:14:36 +0900
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: balbir@...ux.vnet.ibm.com
Cc: linux-mm@...ck.org, Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
YAMAMOTO Takashi <yamamoto@...inux.co.jp>,
Bharata B Rao <bharata@...ibm.com>,
Paul Menage <menage@...gle.com>, lizf@...fujitsu.com,
linux-kernel@...r.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
David Rientjes <rientjes@...gle.com>,
Pavel Emelianov <xemul@...nvz.org>,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Rik van Riel <riel@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 4/4] Memory controller soft limit reclaim on contention
(v4)
On Fri, 6 Mar 2009 15:31:55 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> > > + if (wait)
> > > + wait_for_completion(&mem->wait_on_soft_reclaim);
> > > }
> > What ???? Why we have to wait here...holding mmap->sem...This is too bad.
> >
>
> Since mmap_sem is no longer used for pthread_mutex*, I was not sure.
> That is why I added the comment asking for more review and see what
> people think about it. We get here only when
>
> 1. The memcg is over its soft limit
> 2. Tasks/threads belonging to memcg are faulting in more pages
>
> The idea is to throttle them. If we did reclaim inline, like we do for
> hard limits, we can still end up holding mmap_sem for a long time.
>
This "throttle" is hard to measuer the effect and IIUC, not implemneted in
vmscan.c ...for global try_to_free_pages() yet.
Under memory shortage. before reaching here, the thread already called
try_to_free_pages() or check some memory shorage conditions because
it called alloc_pages(). So, waiting here is redundant and gives it
too much penaly.
> > > + /*
> > > + * This loop can run a while, specially if mem_cgroup's continuously
> > > + * keep exceeding their soft limit and putting the system under
> > > + * pressure
> > > + */
> > > + do {
> > > + mem = mem_cgroup_get_largest_soft_limit_exceeding_node();
> > > + if (!mem)
> > > + break;
> > > + usage = mem_cgroup_get_node_zone_usage(mem, zone, nid);
> > > + if (!usage)
> > > + goto skip_reclaim;
> >
> > Why this works well ? if "mem" is the laragest, it will be inserted again
> > as the largest. Do I miss any ?
> >
>
> No that is correct, but when reclaim is initiated from a different
> zone/node combination, we still want mem to show up.
....
your logic is
==
nr_reclaimd = 0;
do {
mem = select victim.
remvoe victim from the RBtree (the largest usage one is selected)
if (victim is not good)
goto skip this.
reclaimed += shirnk_zone.
skip_this:
if (mem is still exceeds soft limit)
insert RB tree again.
} while(!nr_reclaimed)
==
When this exits loop ?
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists