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>
next prev 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: linkBe 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.