From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 1A7128D003B for ; Fri, 22 Apr 2011 23:49:48 -0400 (EDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p3N3nhnS000485 for ; Fri, 22 Apr 2011 20:49:43 -0700 Received: from qwc23 (qwc23.prod.google.com [10.241.193.151]) by hpaq1.eem.corp.google.com with ESMTP id p3N3nANn016833 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 22 Apr 2011 20:49:42 -0700 Received: by qwc23 with SMTP id 23so466061qwc.3 for ; Fri, 22 Apr 2011 20:49:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DB24A62.7060602@redhat.com> References: <1303185466-2532-1-git-send-email-yinghan@google.com> <20110421025107.GG2333@cmpxchg.org> <20110421130016.3333cb39.kamezawa.hiroyu@jp.fujitsu.com> <20110421050851.GI2333@cmpxchg.org> <20110423013534.GK2333@cmpxchg.org> <20110423023407.GN2333@cmpxchg.org> <4DB24A62.7060602@redhat.com> Date: Fri, 22 Apr 2011 20:49:41 -0700 Message-ID: Subject: Re: [PATCH V6 00/10] memcg: per cgroup background reclaim From: Ying Han Content-Type: multipart/alternative; boundary=0016364eec7e44d32704a18ddd37 Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Johannes Weiner , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Minchan Kim , Daisuke Nishimura , Balbir Singh , Tejun Heo , Pavel Emelyanov , Andrew Morton , Li Zefan , Mel Gorman , Christoph Lameter , Hugh Dickins , Michal Hocko , Dave Hansen , Zhu Yanhai , linux-mm@kvack.org --0016364eec7e44d32704a18ddd37 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 22, 2011 at 8:41 PM, Rik van Riel wrote: > On 04/22/2011 11:33 PM, Ying Han wrote: > > Now we would like to launch another job C, since we know there are A(16G >> - 10G) + B(16G - 10G) = 12G "cold" memory can be reclaimed (w/o >> impacting the A and B's performance). So what will happen >> >> 1. start running C on the host, which triggers global memory pressure >> right away. If the reclaim is fast, C start growing with the free pages >> from A and B. >> >> However, it might be possible that the reclaim can not catch-up with the >> job's page allocation. We end up with either OOM condition or >> performance spike on any of the running jobs. >> >> One way to improve it is to set a wmark on either A/B to be proactively >> reclaiming pages before launching C. The global memory pressure won't >> help much here since we won't trigger that. >> >> min_free_kbytes more or less indirectly provides the same on a global >> level, but I don't think anybody tunes it just for aggressiveness of >> background reclaim. >> > > This sounds like yet another reason to have a tunable that > can increase the gap between min_free_kbytes and low_free_kbytes > (automatically scaled to size in every zone). > > The realtime people want this to reduce allocation latencies. > > I want it for dynamic virtual machine resizing, without the > memory fragmentation inherent in balloons (which would destroy > the performance benefit of transparent hugepages). > > Now Google wants it for job placement. > To clarify a bit, we scale the min_free_kbytes to reduce the likelyhood of page allocation failure. This is still the global per-zone page allocation, and is different from the memcg discussion we have in this thread. To be more specific, our case is more or less caused by the 128M fake node size. Anyway, this is different from what have been discussed so far on this thread. :) --Ying > > Is there any good reason we can't have a low watermark > equivalent to min_free_kbytes? :) > > -- > All rights reversed > --0016364eec7e44d32704a18ddd37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2011 at 8:41 PM, Rik van= Riel <riel@redhat.= com> wrote:
On 04/22/2011 11:33 PM, Ying Han wrote:

Now we would like to launch another job C, since we know there are A(16G - 10G) + B(16G - 10G) =A0=3D 12G "cold" memory can be reclaimed (= w/o
impacting the A and B's performance). So what will happen

1. start running C on the host, which triggers global memory pressure
right away. If the reclaim is fast, C start growing with the free pages
from A and B.

However, it might be possible that the reclaim can not catch-up with the job's page allocation. We end up with either OOM condition or
performance spike on any of the running jobs.

One way to improve it is to set a wmark on either A/B to be proactively
reclaiming pages before launching C. The global memory pressure won't help much here since we won't trigger that.

=A0 =A0min_free_kbytes more or less indirectly provides the same on a glob= al
=A0 =A0level, but I don't think anybody tunes it just for aggressivene= ss of
=A0 =A0background reclaim.

This sounds like yet another reason to have a tunable that
can increase the gap between min_free_kbytes and low_free_kbytes
(automatically scaled to size in every zone).

The realtime people want this to reduce allocation latencies.

I want it for dynamic virtual machine resizing, without the
memory fragmentation inherent in balloons (which would destroy
the performance benefit of transparent hugepages).

Now Google wants it for job placement.

= To clarify a bit, we scale the min_free_kbytes to reduce the likelyhood of = page allocation failure. This is still the global per-zone page allocation,= and is different from the memcg discussion we have in this thread. To be m= ore specific, our case is more or less caused by the 128M fake node size.

Anyway, this is different from what have been discussed= so far on this thread. :)

--Ying

Is there any good reason we can't have a low watermark
equivalent to min_free_kbytes? :)

--
All rights reversed

--0016364eec7e44d32704a18ddd37-- -- 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