All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Davies <richard.davies@elastichosts.com>
To: Rik van Riel <riel@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Satoru Moriya <satoru.moriya@hds.com>,
	Jerome Marchand <jmarchan@redhat.com>,
	"jweiner@redhat.com" <jweiner@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lwoodman@redhat.com" <lwoodman@redhat.com>,
	"shaohua.li@intel.com" <shaohua.li@intel.com>,
	"dle-develop@lists.sourceforge.net"
	<dle-develop@lists.sourceforge.net>,
	Seiji Aguchi <seiji.aguchi@hds.com>,
	Minchan Kim <minchan.kim@gmail.com>
Subject: Re: [RFC][PATCH] avoid swapping out with swappiness==0
Date: Mon, 21 May 2012 08:12:26 +0100	[thread overview]
Message-ID: <20120521071226.GJ29495@alpha.arachsys.com> (raw)
In-Reply-To: <4FA82C11.2030805@redhat.com>

Hi Satoru,

Rik van Riel wrote:
> KOSAKI Motohiro wrote:
> > Richard Davies wrote:
> > >Satoru Moriya wrote:
> > > > > I have run into problems with heavy swapping with swappiness==0 and
> > > > > was pointed to this thread (
> > > > > http://marc.info/?l=linux-mm&m=133522782307215 )
> > > >
> > > > Did you test this patch with your workload?
> > >
> > > I haven't yet tested this patch. It takes a long time since these are
> > > production machines, and the bug itself takes several weeks of
> > > production use to really show up.
> > >
> > > Rik van Riel has pointed out a lot of VM tweaks that he put into 3.4:
> > > http://marc.info/?l=linux-mm&m=133536506926326
> > >
> > > My intention is to reboot half of our machines into plain 3.4 once it
> > > is out, and half onto 3.4 + your patch.
> > >
> > > Then we can compare behaviour.
> > >
> > > Will your patch apply cleanly on 3.4?
> >
> > Note. This patch doesn't solve your issue. This patch mean,
> > when occuring very few swap io, it change to 0. But you said
> > you are seeing eager swap io. As Dave already pointed out, your
> > machine have buffer head issue.
> >
> > So, this thread is pointless.
>
> Running KVM guests directly off block devices results in a lot
> of buffer cache.
>
> I suspect that this patch will in fact fix Richard's issue.
>
> The patch is small, fairly simple and looks like it will fix
> people's problems. It also makes swappiness=0 behave the way
> most people seem to imagine it would work.
>
> If it works for a few people (test results), I believe we
> might as well merge it.
>
> Yes, for cgroups we may need additional logic, but we can
> sort that out as we go along.

Now that 3.4 is out with Rik's fixes, I'm keen to start testing with and
without this extra patch.

Satoru - should I just apply your original patch (most likely), or do you
need to update for the final released kernel?

Thanks,

Richard.

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

WARNING: multiple messages have this Message-ID (diff)
From: Richard Davies <richard.davies@elastichosts.com>
To: Rik van Riel <riel@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Satoru Moriya <satoru.moriya@hds.com>,
	Jerome Marchand <jmarchan@redhat.com>,
	"jweiner@redhat.com" <jweiner@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lwoodman@redhat.com" <lwoodman@redhat.com>,
	"shaohua.li@intel.com" <shaohua.li@intel.com>,
	"dle-develop@lists.sourceforge.net" 
	<dle-develop@lists.sourceforge.net>,
	Seiji Aguchi <seiji.aguchi@hds.com>,
	Minchan Kim <minchan.kim@gmail.com>
Subject: Re: [RFC][PATCH] avoid swapping out with swappiness==0
Date: Mon, 21 May 2012 08:12:26 +0100	[thread overview]
Message-ID: <20120521071226.GJ29495@alpha.arachsys.com> (raw)
In-Reply-To: <4FA82C11.2030805@redhat.com>

Hi Satoru,

Rik van Riel wrote:
> KOSAKI Motohiro wrote:
> > Richard Davies wrote:
> > >Satoru Moriya wrote:
> > > > > I have run into problems with heavy swapping with swappiness==0 and
> > > > > was pointed to this thread (
> > > > > http://marc.info/?l=linux-mm&m=133522782307215 )
> > > >
> > > > Did you test this patch with your workload?
> > >
> > > I haven't yet tested this patch. It takes a long time since these are
> > > production machines, and the bug itself takes several weeks of
> > > production use to really show up.
> > >
> > > Rik van Riel has pointed out a lot of VM tweaks that he put into 3.4:
> > > http://marc.info/?l=linux-mm&m=133536506926326
> > >
> > > My intention is to reboot half of our machines into plain 3.4 once it
> > > is out, and half onto 3.4 + your patch.
> > >
> > > Then we can compare behaviour.
> > >
> > > Will your patch apply cleanly on 3.4?
> >
> > Note. This patch doesn't solve your issue. This patch mean,
> > when occuring very few swap io, it change to 0. But you said
> > you are seeing eager swap io. As Dave already pointed out, your
> > machine have buffer head issue.
> >
> > So, this thread is pointless.
>
> Running KVM guests directly off block devices results in a lot
> of buffer cache.
>
> I suspect that this patch will in fact fix Richard's issue.
>
> The patch is small, fairly simple and looks like it will fix
> people's problems. It also makes swappiness=0 behave the way
> most people seem to imagine it would work.
>
> If it works for a few people (test results), I believe we
> might as well merge it.
>
> Yes, for cgroups we may need additional logic, but we can
> sort that out as we go along.

Now that 3.4 is out with Rik's fixes, I'm keen to start testing with and
without this extra patch.

Satoru - should I just apply your original patch (most likely), or do you
need to update for the final released kernel?

Thanks,

Richard.

  parent reply	other threads:[~2012-05-21  7:12 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-02 17:36 [RFC][PATCH] avoid swapping out with swappiness==0 Satoru Moriya
2012-03-02 17:36 ` Satoru Moriya
2012-03-02 22:47 ` Rik van Riel
2012-03-02 22:47   ` Rik van Riel
2012-03-02 23:43   ` Satoru Moriya
2012-03-02 23:43     ` Satoru Moriya
2012-03-03  2:29   ` Hillf Danton
2012-03-03  2:29     ` Hillf Danton
2012-03-04  6:57 ` Minchan Kim
2012-03-04  6:57   ` Minchan Kim
2012-03-05 21:38   ` Satoru Moriya
2012-03-05 21:38     ` Satoru Moriya
2012-03-05 13:49 ` Rik van Riel
2012-03-05 13:49   ` Rik van Riel
2012-03-05 21:56 ` Johannes Weiner
2012-03-05 21:56   ` Johannes Weiner
2012-03-07 17:19   ` KOSAKI Motohiro
2012-03-07 17:19     ` KOSAKI Motohiro
2012-03-07 18:18     ` Satoru Moriya
2012-03-07 18:18       ` Satoru Moriya
2012-03-30 22:44       ` Satoru Moriya
2012-03-30 22:44         ` Satoru Moriya
2012-04-02 17:10         ` KOSAKI Motohiro
2012-04-02 17:10           ` KOSAKI Motohiro
2012-04-03 11:25           ` Jerome Marchand
2012-04-03 11:25             ` Jerome Marchand
2012-04-03 15:15             ` Satoru Moriya
2012-04-03 15:15               ` Satoru Moriya
2012-04-04 17:38             ` KOSAKI Motohiro
2012-04-04 17:38               ` KOSAKI Motohiro
2012-04-21  0:21               ` Satoru Moriya
2012-04-21  0:21                 ` Satoru Moriya
2012-05-11 21:11                 ` Satoru Moriya
2012-05-11 21:11                   ` Satoru Moriya
2012-05-12 22:21                   ` Rik van Riel
2012-05-12 22:21                     ` Rik van Riel
2012-04-24  8:20       ` Richard Davies
2012-04-24  8:20         ` Richard Davies
2012-04-24 22:14         ` Satoru Moriya
2012-04-24 22:14           ` Satoru Moriya
2012-04-26 14:26           ` Richard Davies
2012-04-26 14:26             ` Richard Davies
2012-04-26 15:41             ` KOSAKI Motohiro
2012-04-26 15:41               ` KOSAKI Motohiro
2012-05-07 20:09               ` Rik van Riel
2012-05-07 20:09                 ` Rik van Riel
2012-05-08  0:05                 ` Minchan Kim
2012-05-08  0:05                   ` Minchan Kim
2012-05-21  7:12                 ` Richard Davies [this message]
2012-05-21  7:12                   ` Richard Davies
2012-05-21 13:39                   ` Satoru Moriya
2012-05-21 13:39                     ` Satoru Moriya
2012-04-26 14:50         ` Christoph Lameter
2012-04-26 14:50           ` Christoph Lameter
2012-04-26 15:37           ` KOSAKI Motohiro
2012-04-26 15:37             ` KOSAKI Motohiro
2012-04-26 16:08             ` Richard Davies
2012-04-26 16:08               ` Richard Davies
2012-04-26 18:20             ` Christoph Lameter
2012-04-26 18:20               ` Christoph Lameter
2012-04-27 13:55           ` Rik van Riel
2012-04-27 13:55             ` Rik van Riel
2012-05-07 20:11 ` Rik van Riel
2012-05-07 20:11   ` Rik van Riel

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=20120521071226.GJ29495@alpha.arachsys.com \
    --to=richard.davies@elastichosts.com \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=jmarchan@redhat.com \
    --cc=jweiner@redhat.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.com \
    --cc=minchan.kim@gmail.com \
    --cc=riel@redhat.com \
    --cc=satoru.moriya@hds.com \
    --cc=seiji.aguchi@hds.com \
    --cc=shaohua.li@intel.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.