From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id 0405C900086 for ; Mon, 18 Apr 2011 22:42:47 -0400 (EDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p3J2gdqS025678 for ; Mon, 18 Apr 2011 19:42:39 -0700 Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by wpaz37.hot.corp.google.com with ESMTP id p3J2ftti023484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 18 Apr 2011 19:42:38 -0700 Received: by qyk7 with SMTP id 7so1683364qyk.5 for ; Mon, 18 Apr 2011 19:42:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1302909815-4362-1-git-send-email-yinghan@google.com> <1302909815-4362-7-git-send-email-yinghan@google.com> Date: Mon, 18 Apr 2011 19:42:37 -0700 Message-ID: Subject: Re: [PATCH V5 06/10] Per-memcg background reclaim. From: Ying Han Content-Type: multipart/alternative; boundary=000e0cdfd08213747d04a13c765b Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: KOSAKI Motohiro , Daisuke Nishimura , Balbir Singh , Tejun Heo , Pavel Emelyanov , KAMEZAWA Hiroyuki , Andrew Morton , Li Zefan , Mel Gorman , Christoph Lameter , Johannes Weiner , Rik van Riel , Hugh Dickins , Michal Hocko , Dave Hansen , Zhu Yanhai , linux-mm@kvack.org --000e0cdfd08213747d04a13c765b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 18, 2011 at 4:32 PM, Minchan Kim wrote: > On Tue, Apr 19, 2011 at 6:38 AM, Ying Han wrote: > > > > > > On Sun, Apr 17, 2011 at 8:51 PM, Minchan Kim > wrote: > >> > >> On Sat, Apr 16, 2011 at 8:23 AM, Ying Han wrote: > >> > + > >> > + sc->nr_scanned = 0; > >> > + shrink_zone(priority, zone, sc); > >> > + total_scanned += sc->nr_scanned; > >> > + > >> > + /* > >> > + * If we've done a decent amount of scanning and > >> > + * the reclaim ratio is low, start doing writepage > >> > + * even in laptop mode > >> > + */ > >> > + if (total_scanned > SWAP_CLUSTER_MAX * 2 && > >> > + total_scanned > sc->nr_reclaimed + > sc->nr_reclaimed > >> > / 2) { > >> > + sc->may_writepage = 1; > >> > >> I don't want to add more random write any more although we don't have > >> a trouble of real memory shortage. > > > > > >> > >> Do you have any reason to reclaim memory urgently as writing dirty > pages? > >> Maybe if we wait a little bit of time, flusher would write out the page. > > > > We would like to reduce the writing dirty pages from page reclaim, > > especially from direct reclaim. AFAIK, the try_to_free_mem_cgroup_pages() > > still need to write dirty pages when there is a need. removing this from > the > > per-memcg kswap will only add more pressure to the per-memcg direct > reclaim, > > which seems to be worse. (stack overflow as one example which we would > like > > to get rid of) > > > > Stack overflow would be another topic. > > Normal situation : > > The softlimit memory pressure of memcg isn't real memory shortage and > if we have gap between hardlimit and softlimit, periodic writeback of > flusher would write it out before reaching the hardlimit. In the end, > direct reclaim don't need to write it out. > > Exceptional situation : > > Of course, it doesn't work well in congestion of bdi, sudden big > memory consumption in memcg in wrong [hard/soft]limit(small gap) > configuration of administrator. > > I think we have to design it by normal situation. > The point is that softlimit isn't real memory shortage so that we are > not urgent. > This patch is not dealing with soft_limit, but hard_limit. The soft_limit reclaim which we talked about during LSF is something i am currently looking at right now. This patch is doing the per-memcg background reclaim which based on the watermarks calculated on the hard_limit. We don't have the memcg entering the direct reclaim each time it is reaching the hard_limit, so we add the background reclaim which reclaiming pages proactively. > How about adding new function which checks global memory pressure and > if we have a trouble by global memory pressure, we can change > may_write with 1 dynamically in memcg_kswapd? > Like I mentioned, the may_write is still needed in this case otherwise we are just put this further to per-memcg direct reclaim. Thanks --Ying > -- > Kind regards, > Minchan Kim > --000e0cdfd08213747d04a13c765b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 18, 2011 at 4:32 PM, Minchan= Kim <minchan= .kim@gmail.com> wrote:
On Tue, Apr 19, 2011 at 6:38 AM, Ying Han <yinghan@google.com> wrote:
>
>
> On Sun, Apr 17, 2011 at 8:51 PM, Minchan Kim <minchan.kim@gmail.com> wrote:
>>
>> On Sat, Apr 16, 2011 at 8:23 AM, Ying Han <yinghan@google.com> wrote:
>> > +
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 sc->nr_scanned =3D 0;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 shrink_zone(priority, zone, sc)= ;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 total_scanned +=3D sc->nr_sc= anned;
>> > +
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /*
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* If we've done a decent= amount of scanning and
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the reclaim ratio is low, = start doing writepage
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* even in laptop mode
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (total_scanned > SWAP_CLU= STER_MAX * 2 &&
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 total_scanned > sc-&= gt;nr_reclaimed + sc->nr_reclaimed
>> > / 2) {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sc->may_writ= epage =3D 1;
>>
>> I don't want to add more random write any more although we don= 't have
>> a trouble of real memory shortage.
>
>
>>
>> Do you have any reason to reclaim memory urgently as writing dirty= pages?
>> Maybe if we wait a little bit of time, flusher would write out the= page.
>
> We would like to reduce the writing dirty pages from page reclaim,
> especially from direct reclaim. AFAIK, the=A0try_to_free_mem_cgroup_pa= ges()
> still need to write dirty pages when there is a need. removing this fr= om the
> per-memcg kswap will only add more pressure to the per-memcg direct re= claim,
> which seems to be worse. (stack overflow as one example which we would= like
> to get rid of)
>

Stack overflow would be another topic.

Normal situation :

The softlimit memory pressure of memcg isn't real memory shortage and if we have gap between hardlimit and softlimit, periodic writeback of
flusher would write it out before reaching the hardlimit. In the end,
direct reclaim don't need to write it out.

Exceptional situation :

Of course, it doesn't work well in congestion of bdi, sudden big
memory consumption in memcg in wrong [hard/soft]limit(small gap)
configuration of administrator.

I think we have to design it by normal situation.
The point is that softlimit isn't real memory shortage so that we are not urgent.

This patch is not dealing w= ith soft_limit, but hard_limit. The soft_limit reclaim which we talked abou= t during LSF
is something i am currently looking at right now. Th= is patch is doing the per-memcg background reclaim which
based on the watermarks calculated on the hard_limit. We don't hav= e the memcg entering the direct reclaim each
time it is reaching = the hard_limit, so we add the background reclaim which reclaiming pages pro= actively.


How about adding new function which checks global memory pressure and
if we have a trouble by global memory pressure, we can change
may_write with 1 dynamically in memcg_kswapd?
=A0
Like I mentioned, the may_write is still needed in this case other= wise we are just put this further to per-memcg
direct reclaim.


Thanks

--Ying
--
Kind regards,
Minchan Kim

--000e0cdfd08213747d04a13c765b-- -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org