All of lore.kernel.org
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Mel Gorman <mgorman@suse.de>, Greg Thelen <gthelen@google.com>,
	Jan Kara <jack@suse.cz>,
	"bsingharora@gmail.com" <bsingharora@gmail.com>,
	Hugh Dickins <hughd@google.com>, Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, Ying Han <yinghan@google.com>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>,
	Minchan Kim <minchan.kim@gmail.com>
Subject: Re: reclaim the LRU lists full of dirty/writeback pages
Date: Thu, 16 Feb 2012 12:52:21 +0900	[thread overview]
Message-ID: <20120216125221.81424ebc.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20120216030415.GA17597@localhost>

On Thu, 16 Feb 2012 11:04:15 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:

> On Thu, Feb 16, 2012 at 09:00:37AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 14 Feb 2012 21:18:12 +0800
> > Wu Fengguang <fengguang.wu@intel.com> wrote:
> > 
> > > 
> > > --- linux.orig/include/linux/backing-dev.h	2012-02-14 19:43:06.000000000 +0800
> > > +++ linux/include/linux/backing-dev.h	2012-02-14 19:49:26.000000000 +0800
> > > @@ -304,6 +304,8 @@ void clear_bdi_congested(struct backing_
> > >  void set_bdi_congested(struct backing_dev_info *bdi, int sync);
> > >  long congestion_wait(int sync, long timeout);
> > >  long wait_iff_congested(struct zone *zone, int sync, long timeout);
> > > +long reclaim_wait(long timeout);
> > > +void reclaim_rotated(void);
> > >  
> > >  static inline bool bdi_cap_writeback_dirty(struct backing_dev_info *bdi)
> > >  {
> > > --- linux.orig/mm/backing-dev.c	2012-02-14 19:26:15.000000000 +0800
> > > +++ linux/mm/backing-dev.c	2012-02-14 20:09:45.000000000 +0800
> > > @@ -873,3 +873,38 @@ out:
> > >  	return ret;
> > >  }
> > >  EXPORT_SYMBOL(wait_iff_congested);
> > > +
> > > +static DECLARE_WAIT_QUEUE_HEAD(reclaim_wqh);
> > > +
> > > +/**
> > > + * reclaim_wait - wait for some pages being rotated to the LRU tail
> > > + * @timeout: timeout in jiffies
> > > + *
> > > + * Wait until @timeout, or when some (typically PG_reclaim under writeback)
> > > + * pages rotated to the LRU so that page reclaim can make progress.
> > > + */
> > > +long reclaim_wait(long timeout)
> > > +{
> > > +	long ret;
> > > +	unsigned long start = jiffies;
> > > +	DEFINE_WAIT(wait);
> > > +
> > > +	prepare_to_wait(&reclaim_wqh, &wait, TASK_KILLABLE);
> > > +	ret = io_schedule_timeout(timeout);
> > > +	finish_wait(&reclaim_wqh, &wait);
> > > +
> > > +	trace_writeback_reclaim_wait(jiffies_to_usecs(timeout),
> > > +				     jiffies_to_usecs(jiffies - start));
> > > +
> > > +	return ret;
> > > +}
> > > +EXPORT_SYMBOL(reclaim_wait);
> > > +
> > > +void reclaim_rotated()
> > > +{
> > > +	wait_queue_head_t *wqh = &reclaim_wqh;
> > > +
> > > +	if (waitqueue_active(wqh))
> > > +		wake_up(wqh);
> > > +}
> > > +
> > 
> > Thank you.
> > 
> > I like this approach. A nitpick is that this may wake up all waiters 
> > in the system when a memcg is rotated.
> 
> Thank you. It sure helps to start it simple :-)
> 
> > How about wait_event() + condition by bitmap (using per memcg unique IDs.) ?
> 
> I'm not sure how to manage the bitmap. The idea in my mind is to
> 
> - maintain a memcg->pages_rotated counter
> 
> - in reclaim_wait(), grab the current ->pages_rotated value before
>   going to wait, compare it to the new value on every wakeup, and
>   return to the user when seeing a different ->pages_rotated value.
>   (this cannot stop waking up multiple tasks in the same memcg...) 
> 
> Does that sound reasonable?
> 

Maybe. But there may be problem in looking up memcg from page at every
rotation. I think it's ok to start with a way ignoring per-memcg status.
Sorry for noise.

Thanks,
-Kame

--
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-16  3:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08  7:55 memcg writeback (was Re: [Lsf-pc] [LSF/MM TOPIC] memcg topics.) Greg Thelen
2012-02-08  9:31 ` Wu Fengguang
2012-02-08 20:54   ` Ying Han
2012-02-09 13:50     ` Wu Fengguang
2012-02-13 18:40       ` Ying Han
2012-02-10  5:51   ` Greg Thelen
2012-02-10  5:52     ` Greg Thelen
2012-02-10  9:20       ` Wu Fengguang
2012-02-10 11:47     ` Wu Fengguang
2012-02-11 12:44       ` reclaim the LRU lists full of dirty/writeback pages Wu Fengguang
2012-02-11 14:55         ` Rik van Riel
2012-02-12  3:10           ` Wu Fengguang
2012-02-12  6:45             ` Wu Fengguang
2012-02-13 15:43             ` Jan Kara
2012-02-14 10:03               ` Wu Fengguang
2012-02-14 13:29                 ` Jan Kara
2012-02-16  4:00                   ` Wu Fengguang
2012-02-16 12:44                     ` Jan Kara
2012-02-16 13:32                       ` Wu Fengguang
2012-02-16 14:06                         ` Wu Fengguang
2012-02-17 16:41                     ` Wu Fengguang
2012-02-20 14:00                       ` Jan Kara
2012-02-14 10:19         ` Mel Gorman
2012-02-14 13:18           ` Wu Fengguang
2012-02-14 13:35             ` Wu Fengguang
2012-02-14 15:51             ` Mel Gorman
2012-02-16  9:50               ` Wu Fengguang
2012-02-16 17:31                 ` Mel Gorman
2012-02-27 14:24                   ` Fengguang Wu
2012-02-16  0:00             ` KAMEZAWA Hiroyuki
2012-02-16  3:04               ` Wu Fengguang
2012-02-16  3:52                 ` KAMEZAWA Hiroyuki [this message]
2012-02-16  4:05                   ` 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=20120216125221.81424ebc.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=bsingharora@gmail.com \
    --cc=fengguang.wu@intel.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=minchan.kim@gmail.com \
    --cc=riel@redhat.com \
    --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.