From: Andrew Morton <akpm@linux-foundation.org> To: Rik van Riel <riel@redhat.com> Cc: Randy Dunlap <rdunlap@xenotime.net>, Satoru Moriya <smoriya@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lwoodman@redhat.com, Seiji Aguchi <saguchi@redhat.com>, hughd@google.com, hannes@cmpxchg.org Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable Date: Thu, 1 Sep 2011 14:58:19 -0700 [thread overview] Message-ID: <20110901145819.4031ef7c.akpm@linux-foundation.org> (raw) In-Reply-To: <20110901152650.7a63cb8b@annuminas.surriel.com> On Thu, 1 Sep 2011 15:26:50 -0400 Rik van Riel <riel@redhat.com> wrote: > Add a userspace visible knob argh. Fear and hostility at new knobs which need to be maintained for ever, even if the underlying implementation changes. Unfortunately, this one makes sense. > to tell the VM to keep an extra amount > of memory free, by increasing the gap between each zone's min and > low watermarks. > > This is useful for realtime applications that call system > calls and have a bound on the number of allocations that happen > in any short time period. In this application, extra_free_kbytes > would be left at an amount equal to or larger than than the > maximum number of allocations that happen in any burst. _is_ it useful? Proof? Who is requesting this? Have they tested it? Results? > It may also be useful to reduce the memory use of virtual > machines (temporarily?), in a way that does not cause memory > fragmentation like ballooning does. Maybe. You need to alter the setting, then somehow persuade all the targeted kswapd's to start running, then somehow determine that they've done their thing, then unalter the /proc setting. Not the best API we've ever designed ;) > ... > > +extra_free_kbytes > + > +This parameter tells the VM to keep extra free memory between the threshold > +where background reclaim (kswapd) kicks in, and the threshold where direct > +reclaim (by allocating processes) kicks in. > + > +This is useful for workloads that require low latency memory allocations > +and have a bounded burstiness in memory allocations, for example a > +realtime application that receives and transmits network traffic > +(causing in-kernel memory allocations) with a maximum total message burst > +size of 200MB may need 200MB of extra free memory to avoid direct reclaim > +related latencies. > + > +============================================================== It's upsetting that the names min_free_kbytes and extra_free_kbytes don't map onto the kernel variables (WMARK_MIN, WMARK_LOW, WMARK_HIGH) and also that they just aren't very communicative. Oh well, doesn't matter much. > ... > +/* > + * Extra memory for the system to try freeing. Used to temporarily > + * free memory, to make space for new workloads. Anyone can allocate > + * down to the min watermarks controlled by min_free_kbytes above. > + */ The comment isn't really complete, is it? There are valid use cases where an alteration here isn't temporary.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org> To: Rik van Riel <riel@redhat.com> Cc: Randy Dunlap <rdunlap@xenotime.net>, Satoru Moriya <smoriya@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lwoodman@redhat.com, Seiji Aguchi <saguchi@redhat.com>, hughd@google.com, hannes@cmpxchg.org Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable Date: Thu, 1 Sep 2011 14:58:19 -0700 [thread overview] Message-ID: <20110901145819.4031ef7c.akpm@linux-foundation.org> (raw) In-Reply-To: <20110901152650.7a63cb8b@annuminas.surriel.com> On Thu, 1 Sep 2011 15:26:50 -0400 Rik van Riel <riel@redhat.com> wrote: > Add a userspace visible knob argh. Fear and hostility at new knobs which need to be maintained for ever, even if the underlying implementation changes. Unfortunately, this one makes sense. > to tell the VM to keep an extra amount > of memory free, by increasing the gap between each zone's min and > low watermarks. > > This is useful for realtime applications that call system > calls and have a bound on the number of allocations that happen > in any short time period. In this application, extra_free_kbytes > would be left at an amount equal to or larger than than the > maximum number of allocations that happen in any burst. _is_ it useful? Proof? Who is requesting this? Have they tested it? Results? > It may also be useful to reduce the memory use of virtual > machines (temporarily?), in a way that does not cause memory > fragmentation like ballooning does. Maybe. You need to alter the setting, then somehow persuade all the targeted kswapd's to start running, then somehow determine that they've done their thing, then unalter the /proc setting. Not the best API we've ever designed ;) > ... > > +extra_free_kbytes > + > +This parameter tells the VM to keep extra free memory between the threshold > +where background reclaim (kswapd) kicks in, and the threshold where direct > +reclaim (by allocating processes) kicks in. > + > +This is useful for workloads that require low latency memory allocations > +and have a bounded burstiness in memory allocations, for example a > +realtime application that receives and transmits network traffic > +(causing in-kernel memory allocations) with a maximum total message burst > +size of 200MB may need 200MB of extra free memory to avoid direct reclaim > +related latencies. > + > +============================================================== It's upsetting that the names min_free_kbytes and extra_free_kbytes don't map onto the kernel variables (WMARK_MIN, WMARK_LOW, WMARK_HIGH) and also that they just aren't very communicative. Oh well, doesn't matter much. > ... > +/* > + * Extra memory for the system to try freeing. Used to temporarily > + * free memory, to make space for new workloads. Anyone can allocate > + * down to the min watermarks controlled by min_free_kbytes above. > + */ The comment isn't really complete, is it? There are valid use cases where an alteration here isn't temporary. -- 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-09-01 21:58 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 [this message] 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 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=20110901145819.4031ef7c.akpm@linux-foundation.org \ --to=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=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.