All of lore.kernel.org
 help / color / mirror / Atom feed
From: Satoru Moriya <satoru.moriya@hds.com>
To: David Rientjes <rientjes@google.com>, Rik van Riel <riel@redhat.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	Satoru Moriya <smoriya@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"lwoodman@redhat.com" <lwoodman@redhat.com>,
	Seiji Aguchi <saguchi@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"hughd@google.com" <hughd@google.com>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>
Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable
Date: Tue, 11 Oct 2011 15:20:14 -0400	[thread overview]
Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516CBBC@USINDEVS02.corp.hds.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110072001070.13992@chino.kir.corp.google.com>

On 10/07/2011 11:08 PM, David Rientjes wrote:
> On Thu, 1 Sep 2011, Rik van Riel wrote:
>
> I also
> think that it will cause regressions on other cpu intensive workloads 
> that don't require this extra freed memory because it works as a 
> global heuristic and is not tied to any specific application.

It's yes and no. It may cause regressions on the workloads due to
less amount of available memory. But it may improve the workloads'
performance because they can avoid direct reclaim due to extra
free memory.

Of course if one doesn't need extra free memory, one can turn it
off. I think we can add this feature to cgroup if we want to set
it for any specific process or process group. (Before that we
need to implement min_free_kbytes for cgroup and the implementation
of extra free kbytes strongly depends on it.)

> I think it would be far better to reclaim beyond above the high 
> watermark if the types of workloads that need this tunable can be 
> somehow detected (the worst case scenario is being a prctl() that does 
> synchronous reclaim above the watermark so admins can identify these 
> workloads), or be able to mark allocations within the kernel as 
> potentially coming in large bursts where allocation is problematic.

It may work. But isn't it difficult and/or complex to decide
how much memory we should reclaim beyond high watermark
automatically?

I believe that extra free kbytes is far simpler than them.

Regards,
Satoru

WARNING: multiple messages have this Message-ID (diff)
From: Satoru Moriya <satoru.moriya@hds.com>
To: David Rientjes <rientjes@google.com>, Rik van Riel <riel@redhat.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	Satoru Moriya <smoriya@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"lwoodman@redhat.com" <lwoodman@redhat.com>,
	Seiji Aguchi <saguchi@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"hughd@google.com" <hughd@google.com>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>
Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable
Date: Tue, 11 Oct 2011 15:20:14 -0400	[thread overview]
Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516CBBC@USINDEVS02.corp.hds.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110072001070.13992@chino.kir.corp.google.com>

On 10/07/2011 11:08 PM, David Rientjes wrote:
> On Thu, 1 Sep 2011, Rik van Riel wrote:
>
> I also
> think that it will cause regressions on other cpu intensive workloads 
> that don't require this extra freed memory because it works as a 
> global heuristic and is not tied to any specific application.

It's yes and no. It may cause regressions on the workloads due to
less amount of available memory. But it may improve the workloads'
performance because they can avoid direct reclaim due to extra
free memory.

Of course if one doesn't need extra free memory, one can turn it
off. I think we can add this feature to cgroup if we want to set
it for any specific process or process group. (Before that we
need to implement min_free_kbytes for cgroup and the implementation
of extra free kbytes strongly depends on it.)

> I think it would be far better to reclaim beyond above the high 
> watermark if the types of workloads that need this tunable can be 
> somehow detected (the worst case scenario is being a prctl() that does 
> synchronous reclaim above the watermark so admins can identify these 
> workloads), or be able to mark allocations within the kernel as 
> potentially coming in large bursts where allocation is problematic.

It may work. But isn't it difficult and/or complex to decide
how much memory we should reclaim beyond high watermark
automatically?

I believe that extra free kbytes is far simpler than them.

Regards,
Satoru

--
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:[~2011-10-11 19:20 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01 14:52 [PATCH -mm] add extra free kbytes tunable Rik van Riel
2011-09-01 14:52 ` Rik van Riel
2011-09-01 17:06 ` Randy Dunlap
2011-09-01 17:06   ` Randy Dunlap
2011-09-01 19:26   ` [PATCH -v2 " Rik van Riel
2011-09-01 19:26     ` Rik van Riel
2011-09-01 21:58     ` Andrew Morton
2011-09-01 21:58       ` Andrew Morton
2011-09-01 22:08       ` David Rientjes
2011-09-01 22:08         ` David Rientjes
2011-09-01 22:16         ` Andrew Morton
2011-09-01 22:16           ` Andrew Morton
2011-09-02 16:31       ` Satoru Moriya
2011-09-02 16:31         ` Satoru Moriya
2011-10-13  7:33         ` Minchan Kim
2011-10-13  7:33           ` Minchan Kim
2011-10-13  8:09           ` KAMEZAWA Hiroyuki
2011-10-13  8:09             ` KAMEZAWA Hiroyuki
     [not found]       ` <E1FA588BC672D846BDBB452FCA1E308C2389B4@USINDEVS02.corp.hds.com>
2011-09-15  3:33         ` Satoru Moriya
2011-09-15  3:33           ` Satoru Moriya
2011-09-01 22:09     ` Andrew Morton
2011-09-01 22:09       ` Andrew Morton
2011-09-02 16:26       ` [PATCH -mm] fixes & cleanups for "add extra free kbytes tunable" Rik van Riel
2011-09-02 16:26         ` Rik van Riel
2011-09-30 21:43     ` [PATCH -v2 -mm] add extra free kbytes tunable Johannes Weiner
2011-09-30 21:43       ` Johannes Weiner
2011-10-08  3:08     ` David Rientjes
2011-10-08  3:08       ` David Rientjes
2011-10-10 22:37       ` Andrew Morton
2011-10-10 22:37         ` Andrew Morton
2011-10-11 19:32         ` Satoru Moriya
2011-10-11 19:32           ` Satoru Moriya
2011-10-11 19:54           ` Andrew Morton
2011-10-11 19:54             ` Andrew Morton
2011-10-11 20:23             ` Satoru Moriya
2011-10-11 20:23               ` Satoru Moriya
2011-10-11 20:54               ` Andrew Morton
2011-10-11 20:54                 ` Andrew Morton
2011-10-12 13:09                 ` Rik van Riel
2011-10-12 13:09                   ` Rik van Riel
2011-10-12 19:20                   ` Andrew Morton
2011-10-12 19:20                     ` Andrew Morton
2011-10-12 19:58                     ` Rik van Riel
2011-10-12 19:58                       ` Rik van Riel
2011-10-12 20:26                       ` David Rientjes
2011-10-12 20:26                         ` David Rientjes
2011-10-21 23:48                       ` Satoru Moriya
2011-10-21 23:48                         ` Satoru Moriya
2011-10-23 21:22                         ` David Rientjes
2011-10-23 21:22                           ` David Rientjes
2011-10-25  2:04                           ` Satoru Moriya
2011-10-25  2:04                             ` Satoru Moriya
2011-10-25 21:50                             ` David Rientjes
2011-10-25 21:50                               ` David Rientjes
2011-10-26 18:59                               ` Satoru Moriya
2011-10-26 18:59                                 ` Satoru Moriya
2011-10-12 21:08                 ` Satoru Moriya
2011-10-12 21:08                   ` Satoru Moriya
2011-10-12 22:41                   ` David Rientjes
2011-10-12 22:41                     ` David Rientjes
2011-10-12 23:52                     ` Satoru Moriya
2011-10-12 23:52                       ` Satoru Moriya
2011-10-13  0:01                       ` David Rientjes
2011-10-13  0:01                         ` David Rientjes
2011-10-13  5:35                         ` KAMEZAWA Hiroyuki
2011-10-13  5:35                           ` KAMEZAWA Hiroyuki
2011-10-13 20:55                           ` David Rientjes
2011-10-13 20:55                             ` David Rientjes
2011-10-14 22:16                             ` Satoru Moriya
2011-10-14 22:16                               ` Satoru Moriya
2011-10-14 22:46                               ` David Rientjes
2011-10-14 22:46                                 ` David Rientjes
2011-10-14  5:32                           ` Satoru Moriya
2011-10-14  5:32                             ` Satoru Moriya
2011-10-14  5:06                         ` Satoru Moriya
2011-10-14  5:06                           ` Satoru Moriya
2011-10-11 23:22           ` David Rientjes
2011-10-11 23:22             ` David Rientjes
2011-10-13 16:54             ` Satoru Moriya
2011-10-13 16:54               ` Satoru Moriya
2011-10-13 20:48               ` David Rientjes
2011-10-13 20:48                 ` David Rientjes
2011-10-13 21:11                 ` Rik van Riel
2011-10-13 21:11                   ` Rik van Riel
2011-10-13 22:02                   ` David Rientjes
2011-10-13 22:02                     ` David Rientjes
2011-10-11 19:20       ` Satoru Moriya [this message]
2011-10-11 19:20         ` Satoru Moriya
2011-10-11 21:04         ` David Rientjes
2011-10-11 21:04           ` David Rientjes
2011-10-12 13:13           ` Rik van Riel
2011-10-12 13:13             ` Rik van Riel
2011-10-12 20:21             ` David Rientjes
2011-10-12 20:21               ` David Rientjes
2011-10-13  4:13               ` Rik van Riel
2011-10-13  4:13                 ` Rik van Riel
2011-10-13  5:22                 ` David Rientjes
2011-10-13  5:22                   ` David Rientjes
2011-10-22  0:11                   ` Satoru Moriya
2011-10-22  0:11                     ` Satoru Moriya
2011-09-09 23:01 Satoru Moriya
2011-09-09 23:01 ` Satoru Moriya

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=65795E11DBF1E645A09CEC7EAEE94B9CB516CBBC@USINDEVS02.corp.hds.com \
    --to=satoru.moriya@hds.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=saguchi@redhat.com \
    --cc=smoriya@redhat.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.