All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Greg Thelen <gthelen@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>,
	"bsingharora@gmail.com" <bsingharora@gmail.com>,
	Hugh Dickins <hughd@google.com>, Ying Han <yinghan@google.com>,
	Mel Gorman <mgorman@suse.de>
Subject: Re: [LSF/MM TOPIC] memcg topics.
Date: Thu, 2 Feb 2012 15:54:47 +0800	[thread overview]
Message-ID: <20120202075446.GA6837@localhost> (raw)
In-Reply-To: <CAHH2K0a+srs7A78SdneNG01bbS_Nyq0eCSOA8mrujuE=F2juSg@mail.gmail.com>

On Wed, Feb 01, 2012 at 11:34:36PM -0800, Greg Thelen wrote:
> On Wed, Feb 1, 2012 at 10:33 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > Hi Greg,
> >
> > On Wed, Feb 01, 2012 at 12:24:25PM -0800, Greg Thelen wrote:
> >> 1. how to compute per-container pause based on bdi bandwidth, cgroup
> >> dirty page usage.
> >> 2. how to ensure that writeback will engage even if system and bdi are
> >> below respective background dirty ratios, yet a memcg is above its bg
> >> dirty limit.
> >
> > The solution to (1,2) would be something like this:
> >
> > --- linux-next.orig/mm/page-writeback.c 2012-02-02 14:13:45.000000000 +0800
> > +++ linux-next/mm/page-writeback.c A  A  A 2012-02-02 14:24:11.000000000 +0800
> > @@ -654,6 +654,17 @@ static unsigned long bdi_position_ratio(
> > A  A  A  A pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT;
> > A  A  A  A pos_ratio += 1 << RATELIMIT_CALC_SHIFT;
> >
> > + A  A  A  if (memcg) {
> > + A  A  A  A  A  A  A  long long f;
> > + A  A  A  A  A  A  A  x = div_s64((memcg_setpoint - memcg_dirty) << RATELIMIT_CALC_SHIFT,
> > + A  A  A  A  A  A  A  A  A  A  A  A  A  memcg_limit - memcg_setpoint + 1);
> > + A  A  A  A  A  A  A  f = x;
> > + A  A  A  A  A  A  A  f = f * x >> RATELIMIT_CALC_SHIFT;
> > + A  A  A  A  A  A  A  f = f * x >> RATELIMIT_CALC_SHIFT;
> > + A  A  A  A  A  A  A  f += 1 << RATELIMIT_CALC_SHIFT;
> > + A  A  A  A  A  A  A  pos_ratio = pos_ratio * f >> RATELIMIT_CALC_SHIFT;
> > + A  A  A  }
> > +
> > A  A  A  A /*
> > A  A  A  A  * We have computed basic pos_ratio above based on global situation. If
> > A  A  A  A  * the bdi is over/under its share of dirty pages, we want to scale
> > @@ -1202,6 +1213,8 @@ static void balance_dirty_pages(struct a
> > A  A  A  A  A  A  A  A freerun = dirty_freerun_ceiling(dirty_thresh,
> > A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  A background_thresh);
> > A  A  A  A  A  A  A  A if (nr_dirty <= freerun) {
> > + A  A  A  A  A  A  A  A  A  A  A  if (memcg && memcg_dirty > memcg_freerun)
> > + A  A  A  A  A  A  A  A  A  A  A  A  A  A  A  goto start_writeback;
> > A  A  A  A  A  A  A  A  A  A  A  A current->dirty_paused_when = now;
> > A  A  A  A  A  A  A  A  A  A  A  A current->nr_dirtied = 0;
> > A  A  A  A  A  A  A  A  A  A  A  A current->nr_dirtied_pause =
> > @@ -1209,6 +1222,7 @@ static void balance_dirty_pages(struct a
> > A  A  A  A  A  A  A  A  A  A  A  A break;
> > A  A  A  A  A  A  A  A }
> >
> > +start_writeback:
> > A  A  A  A  A  A  A  A if (unlikely(!writeback_in_progress(bdi)))
> > A  A  A  A  A  A  A  A  A  A  A  A bdi_start_background_writeback(bdi);
> >
> >
> > That makes the minimal change to enforce per-memcg dirty ratio.
> > It could result in a less stable control system, but should still
> > be able to balance things out.
> >
> > Thanks,
> > Fengguang
> 
> Thank you for the quick patch.  It looks promising.  I can imagine how
> this would wake up background writeback.  But I am unsure how
> background writeback will do anything.  It seems like
> over_bground_thresh() would not necessarily see system or bdi dirty
> usage over respective limits.  In previously posted memcg writeback
> patches this involved an fs-writeback.c call to
> mem_cgroups_over_bground_dirty_thresh() to check for memcg dirty limit
> compliance.  Do you think we still need such a call out to memcg from
> writeback?

Yeah I forgot over_bground_thresh().. Obviously it needs to be memcg
aware, too.

Thanks,
Fengguang

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-02-02  8:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01  0:55 [LSF/MM TOPIC] memcg topics KAMEZAWA Hiroyuki
2012-02-01  8:58 ` Glauber Costa
2012-02-02 11:33   ` [LSF/MM TOPIC][ATTEND] " Glauber Costa
2012-02-01 20:24 ` [LSF/MM TOPIC] " Greg Thelen
2012-02-02  6:33   ` Wu Fengguang
2012-02-02  7:34     ` Greg Thelen
2012-02-02  7:54       ` Wu Fengguang [this message]
2012-02-02  7:52     ` Wu Fengguang
2012-02-02 10:39       ` [Lsf-pc] " Jan Kara
2012-02-02 11:04         ` Wu Fengguang
2012-02-02 15:42           ` Jan Kara
2012-02-03  1:26             ` Wu Fengguang
2012-02-03  6:21               ` Greg Thelen
2012-02-03  9:40                 ` Wu Fengguang
2012-02-02 10:15     ` Jan Kara
2012-02-02 11:31       ` Wu Fengguang

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=20120202075446.GA6837@localhost \
    --to=fengguang.wu@intel.com \
    --cc=bsingharora@gmail.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=yinghan@google.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.