From: David Rientjes <rientjes@google.com> To: Rik van Riel <riel@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Satoru Moriya <satoru.moriya@hds.com>, 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>, "hughd@google.com" <hughd@google.com>, "hannes@cmpxchg.org" <hannes@cmpxchg.org> Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable Date: Wed, 12 Oct 2011 13:26:22 -0700 (PDT) [thread overview] Message-ID: <alpine.DEB.2.00.1110121322200.7646@chino.kir.corp.google.com> (raw) In-Reply-To: <4E95F167.5050709@redhat.com> On Wed, 12 Oct 2011, Rik van Riel wrote: > > > The problem is that we may be dealing with bursts, not steady > > > states of allocations. Without knowing the size of a burst, > > > we have no idea when we should wake up kswapd to get enough > > > memory freed ahead of the application's allocations. > > Raising the priority of kswapd to be the highest possible when triggered by rt-tasks should help to reclaim memory faster. If that doesn't work fully with Con's patch on Satoru's testcase then we'll want to extend it to raise the priority for a running kswapd when a higher priority thread calls into the page allocator slowpath. If that also doesn't mitigate the problem entirely, then we'll need to suggest raising min_free_kbytes so these threads have a larger pool of exclusive access to memory when the burst first happens. > > That problem remains with this patch - it just takes a larger burst. > > > > Unless the admin somehow manages to configure the tunable large enough > > to cover the largest burst, and there aren't other applications > > allocating memory during that burst, and the time between bursts is > > sufficient for kswapd to be able to sufficiently replenish free-page > > reserves. All of which sounds rather unlikely. > > It depends on the system. For a setup which is packed to > the brim with workloads, this patch is not likely to help. > On the other hand, on a system that is packed to the brim > with workloads, you are unlikely to get low latencies anyway. > > For situations where people really care about low latencies, > I imagine having dedicated hardware for a workload is not at > all unusual, and the patch works for that. > If it's dedicated hardware, then you should be able to just raise min_free_kbytes so that rt-tasks get exclusive access to a larger amount of memory.
WARNING: multiple messages have this Message-ID (diff)
From: David Rientjes <rientjes@google.com> To: Rik van Riel <riel@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Satoru Moriya <satoru.moriya@hds.com>, 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>, "hughd@google.com" <hughd@google.com>, "hannes@cmpxchg.org" <hannes@cmpxchg.org> Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable Date: Wed, 12 Oct 2011 13:26:22 -0700 (PDT) [thread overview] Message-ID: <alpine.DEB.2.00.1110121322200.7646@chino.kir.corp.google.com> (raw) In-Reply-To: <4E95F167.5050709@redhat.com> On Wed, 12 Oct 2011, Rik van Riel wrote: > > > The problem is that we may be dealing with bursts, not steady > > > states of allocations. Without knowing the size of a burst, > > > we have no idea when we should wake up kswapd to get enough > > > memory freed ahead of the application's allocations. > > Raising the priority of kswapd to be the highest possible when triggered by rt-tasks should help to reclaim memory faster. If that doesn't work fully with Con's patch on Satoru's testcase then we'll want to extend it to raise the priority for a running kswapd when a higher priority thread calls into the page allocator slowpath. If that also doesn't mitigate the problem entirely, then we'll need to suggest raising min_free_kbytes so these threads have a larger pool of exclusive access to memory when the burst first happens. > > That problem remains with this patch - it just takes a larger burst. > > > > Unless the admin somehow manages to configure the tunable large enough > > to cover the largest burst, and there aren't other applications > > allocating memory during that burst, and the time between bursts is > > sufficient for kswapd to be able to sufficiently replenish free-page > > reserves. All of which sounds rather unlikely. > > It depends on the system. For a setup which is packed to > the brim with workloads, this patch is not likely to help. > On the other hand, on a system that is packed to the brim > with workloads, you are unlikely to get low latencies anyway. > > For situations where people really care about low latencies, > I imagine having dedicated hardware for a workload is not at > all unusual, and the patch works for that. > If it's dedicated hardware, then you should be able to just raise min_free_kbytes so that rt-tasks get exclusive access to a larger amount of memory. -- 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-12 20:26 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 [this message] 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=alpine.DEB.2.00.1110121322200.7646@chino.kir.corp.google.com \ --to=rientjes@google.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=saguchi@redhat.com \ --cc=satoru.moriya@hds.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.