All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Davies <richard@arachsys.com>
To: Satoru Moriya <satoru.moriya@hds.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Jerome Marchand <jmarchan@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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>,
	"riel@redhat.com" <riel@redhat.com>,
	"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: Tue, 24 Apr 2012 09:20:19 +0100	[thread overview]
Message-ID: <20120424082019.GA18395@alpha.arachsys.com> (raw)
In-Reply-To: <65795E11DBF1E645A09CEC7EAEE94B9CB951A45F@USINDEVS02.corp.hds.com>

On 03/07/2012 18:18 PM, Satoru Moriya wrote:
> On 03/07/2012 12:19 PM, KOSAKI Motohiro wrote:
>> On 3/5/2012 4:56 PM, Johannes Weiner wrote:
>>> On Fri, Mar 02, 2012 at 12:36:40PM -0500, Satoru Moriya wrote:
>>>>
>>>> This patch changes the behavior with swappiness==0. If we set 
>>>> swappiness==0, the kernel does not swap out completely (for global 
>>>> reclaim until the amount of free pages and filebacked pages in a 
>>>> zone has been reduced to something very very small (nr_free + 
>>>> nr_filebacked < high watermark)).
>>>>
>>>> Any comments are welcome.
>>>
>>> Last time I tried that (getting rid of sc->may_swap, using 
>>> !swappiness), it was rejected it as there were users who relied on 
>>> swapping very slowly with this setting.
>>>
>>> KOSAKI-san, do I remember correctly?  Do you still think it's an 
>>> issue?
>>>
>>> Personally, I still think it's illogical that !swappiness allows 
>>> swapping and would love to see this patch go in.
>> 
>> Thank you. I brought back to memory it. Unfortunately DB folks are 
>> still mainly using RHEL5 generation distros. At that time, swapiness=0 
>> doesn't mean disabling swap.
>> 
>> They want, "don't swap as far as kernel has any file cache page". but 
>> linux don't have such feature. then they used swappiness for emulate 
>> it. So, I think this patch clearly make userland harm. Because of, we 
>> don't have an alternative way.
>
> If they expect the behavior that "don't swap as far as kernel
> has any file cache page", this patch definitely helps them
> because if we set swappiness==0, kernel does not swap out
> *until* nr_free + nr_filebacked < high watermark in the zone.
> It means kernel begins to swap out when nr_free + nr_filebacked
> becomes less than high watermark.
>
> But, yes, this patch actually changes the behavior with
> swappiness==0 and so it may make userland harm. 
>
> How about introducing new value e.g -1 to avoid swap and
> maintain compatibility?

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 )

I strongly believe that Linux should have a way to turn off swapping unless
absolutely necessary. This means that users like us can run with swap
present for emergency use, rather than having to disable it because of the
side effects.

Personally, I feel that swappiness==0 should have this (intuitive) meaning,
and that people running RHEL5 are extremely unlikely to run 3.5 kernels(!)

However, swappiness==-1 or some other hack is definitely better than no
patch.

Richard.

WARNING: multiple messages have this Message-ID (diff)
From: Richard Davies <richard@arachsys.com>
To: Satoru Moriya <satoru.moriya@hds.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Jerome Marchand <jmarchan@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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>,
	"riel@redhat.com" <riel@redhat.com>,
	"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: Tue, 24 Apr 2012 09:20:19 +0100	[thread overview]
Message-ID: <20120424082019.GA18395@alpha.arachsys.com> (raw)
In-Reply-To: <65795E11DBF1E645A09CEC7EAEE94B9CB951A45F@USINDEVS02.corp.hds.com>

On 03/07/2012 18:18 PM, Satoru Moriya wrote:
> On 03/07/2012 12:19 PM, KOSAKI Motohiro wrote:
>> On 3/5/2012 4:56 PM, Johannes Weiner wrote:
>>> On Fri, Mar 02, 2012 at 12:36:40PM -0500, Satoru Moriya wrote:
>>>>
>>>> This patch changes the behavior with swappiness==0. If we set 
>>>> swappiness==0, the kernel does not swap out completely (for global 
>>>> reclaim until the amount of free pages and filebacked pages in a 
>>>> zone has been reduced to something very very small (nr_free + 
>>>> nr_filebacked < high watermark)).
>>>>
>>>> Any comments are welcome.
>>>
>>> Last time I tried that (getting rid of sc->may_swap, using 
>>> !swappiness), it was rejected it as there were users who relied on 
>>> swapping very slowly with this setting.
>>>
>>> KOSAKI-san, do I remember correctly?  Do you still think it's an 
>>> issue?
>>>
>>> Personally, I still think it's illogical that !swappiness allows 
>>> swapping and would love to see this patch go in.
>> 
>> Thank you. I brought back to memory it. Unfortunately DB folks are 
>> still mainly using RHEL5 generation distros. At that time, swapiness=0 
>> doesn't mean disabling swap.
>> 
>> They want, "don't swap as far as kernel has any file cache page". but 
>> linux don't have such feature. then they used swappiness for emulate 
>> it. So, I think this patch clearly make userland harm. Because of, we 
>> don't have an alternative way.
>
> If they expect the behavior that "don't swap as far as kernel
> has any file cache page", this patch definitely helps them
> because if we set swappiness==0, kernel does not swap out
> *until* nr_free + nr_filebacked < high watermark in the zone.
> It means kernel begins to swap out when nr_free + nr_filebacked
> becomes less than high watermark.
>
> But, yes, this patch actually changes the behavior with
> swappiness==0 and so it may make userland harm. 
>
> How about introducing new value e.g -1 to avoid swap and
> maintain compatibility?

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 )

I strongly believe that Linux should have a way to turn off swapping unless
absolutely necessary. This means that users like us can run with swap
present for emergency use, rather than having to disable it because of the
side effects.

Personally, I feel that swappiness==0 should have this (intuitive) meaning,
and that people running RHEL5 are extremely unlikely to run 3.5 kernels(!)

However, swappiness==-1 or some other hack is definitely better than no
patch.

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>

  parent reply	other threads:[~2012-04-24  8:20 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 [this message]
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
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=20120424082019.GA18395@alpha.arachsys.com \
    --to=richard@arachsys.com \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=jmarchan@redhat.com \
    --cc=jweiner@redhat.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=kosaki.motohiro@jp.fujitsu.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.