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>, Andrew Morton <akpm@linux-foundation.org>, Hugh Dickins <hughd@google.com>, "hannes@cmpxchg.org" <hannes@cmpxchg.org> Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Date: Fri, 21 Oct 2011 20:11:20 -0400 [thread overview] Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB4F747B2@USINDEVS02.corp.hds.com> (raw) In-Reply-To: <alpine.DEB.2.00.1110122210030.7572@chino.kir.corp.google.com> On 10/13/2011 01:22 AM, David Rientjes wrote: > On Thu, 13 Oct 2011, Rik van Riel wrote: > >> Furthermore, I am not sure that giving kswapd more CPU time is >> going to help, because kswapd could be stuck on some lock, held >> by a lower priority (or sleeping) context. >> >> I agree that the BFS patch would be worth a try, and would be >> very pleasantly surprised if it worked, but I am not very >> optimistic about it... >> > > It may require a combination of Con's patch, increasing the priority of > kswapd if a higher priority task kicks it in the page allocator, and an > extra bonus on top of the high watermark if it was triggered by a > rt-thread -- similar to ALLOC_HARDER but instead reclaiming to > (high * 1.25). I tested Con's patch. The results are following. 1. delayacct result RECLAIM count delay total delay average --------------------------------------------------------------- normal task w/o Con's patch 210 42685857 203us rt task w/o Con's patch 32 4922368 153us rt task w Con's patch 29 4399320 151us 2. /proc/vmstat result normal task w/o rt task w/o rt task w/ Con's patch Con's patch Con's patch --------------------------------------------------------------------- nr_vmscan_write 0 13160 14536 pgsteal_dma 0 0 0 pgsteal_dma32 182710 175049 169871 pgsteal_normal 10260 9499 13077 pgsteal_movable 0 0 0 pgscan_kswapd_dma 0 0 0 pgscan_kswapd_dma32 127159 149096 147924 pgscan_kswapd_normal 26094 49011 33186 pgscan_kswapd_movable 0 0 0 pgscan_direct_dma 0 0 0 pgscan_direct_dma32 55551 25923 21947 pgscan_direct_normal 7128 3624 2816 pgscan_direct_movable 0 0 0 kswapd_steal 134481 157951 159556 kswapd_inodesteal 0 0 0 kswapd_low_wmark_hit_quickly 0 0 6 kswapd_high_wmark_hit_quickly 0 0 0 allocstall 324 151 128 Unfortunately, it seems that Con's patch does not improve my testcase so much. We may need extra bonus on the high watermark if we take the way above. But necessary bonus depends on workloads, hardware etc., so it can't be solved with fixed bonus, I think. > If we're going to go with extra_free_kbytes, then I'd like to see the test > case posted with a mathematical formula to show me what I should tune it > to be depending on my machine's memory capacity and amount of free RAM > when started (and I can use mem= to test it for various capacities). For > this to be merged, there should be a clear expression that shows what the > ideal setting of the tunable should be rather than asking for trial-and- > error to see what works and what doesn't. If such an expression doesn't > exist, then it's clear that the necessary setting will vary significantly > as the implementation changes from kernel to kernel. Hmm, try and error is tuning itself, isn't it? When we tune a system, we usually set some knobs, run some benchmarks/tests/etc., evaluate the results and decide which is the appropriate value. 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>, Andrew Morton <akpm@linux-foundation.org>, Hugh Dickins <hughd@google.com>, "hannes@cmpxchg.org" <hannes@cmpxchg.org> Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Date: Fri, 21 Oct 2011 20:11:20 -0400 [thread overview] Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB4F747B2@USINDEVS02.corp.hds.com> (raw) In-Reply-To: <alpine.DEB.2.00.1110122210030.7572@chino.kir.corp.google.com> On 10/13/2011 01:22 AM, David Rientjes wrote: > On Thu, 13 Oct 2011, Rik van Riel wrote: > >> Furthermore, I am not sure that giving kswapd more CPU time is >> going to help, because kswapd could be stuck on some lock, held >> by a lower priority (or sleeping) context. >> >> I agree that the BFS patch would be worth a try, and would be >> very pleasantly surprised if it worked, but I am not very >> optimistic about it... >> > > It may require a combination of Con's patch, increasing the priority of > kswapd if a higher priority task kicks it in the page allocator, and an > extra bonus on top of the high watermark if it was triggered by a > rt-thread -- similar to ALLOC_HARDER but instead reclaiming to > (high * 1.25). I tested Con's patch. The results are following. 1. delayacct result RECLAIM count delay total delay average --------------------------------------------------------------- normal task w/o Con's patch 210 42685857 203us rt task w/o Con's patch 32 4922368 153us rt task w Con's patch 29 4399320 151us 2. /proc/vmstat result normal task w/o rt task w/o rt task w/ Con's patch Con's patch Con's patch --------------------------------------------------------------------- nr_vmscan_write 0 13160 14536 pgsteal_dma 0 0 0 pgsteal_dma32 182710 175049 169871 pgsteal_normal 10260 9499 13077 pgsteal_movable 0 0 0 pgscan_kswapd_dma 0 0 0 pgscan_kswapd_dma32 127159 149096 147924 pgscan_kswapd_normal 26094 49011 33186 pgscan_kswapd_movable 0 0 0 pgscan_direct_dma 0 0 0 pgscan_direct_dma32 55551 25923 21947 pgscan_direct_normal 7128 3624 2816 pgscan_direct_movable 0 0 0 kswapd_steal 134481 157951 159556 kswapd_inodesteal 0 0 0 kswapd_low_wmark_hit_quickly 0 0 6 kswapd_high_wmark_hit_quickly 0 0 0 allocstall 324 151 128 Unfortunately, it seems that Con's patch does not improve my testcase so much. We may need extra bonus on the high watermark if we take the way above. But necessary bonus depends on workloads, hardware etc., so it can't be solved with fixed bonus, I think. > If we're going to go with extra_free_kbytes, then I'd like to see the test > case posted with a mathematical formula to show me what I should tune it > to be depending on my machine's memory capacity and amount of free RAM > when started (and I can use mem= to test it for various capacities). For > this to be merged, there should be a clear expression that shows what the > ideal setting of the tunable should be rather than asking for trial-and- > error to see what works and what doesn't. If such an expression doesn't > exist, then it's clear that the necessary setting will vary significantly > as the implementation changes from kernel to kernel. Hmm, try and error is tuning itself, isn't it? When we tune a system, we usually set some knobs, run some benchmarks/tests/etc., evaluate the results and decide which is the appropriate value. 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-22 0:11 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 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 [this message] 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=65795E11DBF1E645A09CEC7EAEE94B9CB4F747B2@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.